Guido van Rossum wrote:
I see four tests fail that passed yesterday:
[...]
< test_threaded_import
Patch attached.
Need any comments?
Index: Lib/tempfile.py
===
--- Lib/tempfile.py (revision 56982)
+++ Lib/tempfile.py (working copy)
On 13/08/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > and you set the newline argument to specify a *specific*,
> > non-universal, newline value
>
> It still seems wrong to not translate the newlines, though,
> since it's still a *text* mode, and the standard Python
> represent
"Kurt B. Kaiser" <[EMAIL PROTECTED]> writes:
>> I now get an IDLE window which crashes as soon as I type something.
>
> Yes, something like
>
> File
> "/home/kbk/PYDOTORG/projects/python/branches/py3k/Lib/lib-tk/Tkinter.py",
> line 1022, in mainloop
> self.tk.mainloop(n)
> TypeError: expec
> The changes you checked in to _tkinter.c fixed WidgetRedirector, and
> those and the other changes you made in idlelib have IDLE working
> without the subprocess.
>
> Thanks very much for working on this!
I doubt that all is working yet, though. So some thorough testing would
probably be necess
Paul> ... that files can have *either* bare \n, *or* the combination
Paul> \r\n, to delimit lines.
As someone else pointed out, \r needs to be supported as well. Many Mac
applications (Excel comes to mind) still emit text files with \r as the line
terminator.
Skip
_
> Say I create a new int-like class, not derived from int, named MyInt.
> And I want to use it like an int, maybe to print it as a hex number:
Then derive that class from "int", for heaven's sake!
Bill
___
Python-3000 mailing list
[email protected]
It's official! The second annual Python Sprint @ Google is happening
again: August 22-25 (Wed-Sat). We're sprinting at two locations, this
time Google headquarters in Mountain View and the Google office in
Chicago (thanks to Brian Fitzpatrick). We'll connect the two sprints
with full-screen videoc
> :f<+015.5 # Floating point, left aligned, always show sign,
> # leading zeros, field width 15 (min), 5 decimal places.
Which has precedence... left alignment or zero padding?
Or should this be an error?
Ron
___
Python-3000 mailin
In article <[EMAIL PROTECTED]>,
"Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum writes:
>
> > However, the old universal newlines feature also set an attibute named
> > 'newlines' on the file object to a tuple of up to three elements
> > giving the actual line endings that
Checked in. But next time please do use SF to submit patches (and feel
free to assign them to me and mail the list about it).
On 8/12/07, Victor Stinner <[EMAIL PROTECTED]> wrote:
> On Sunday 12 August 2007 16:50:05 Barry Warsaw wrote:
> > In r56957 I committed changes to sndhdr.py and imghdr.py s
On 8/11/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > ==
> > ERROR: test_char_write (__main__.TestArrayWrites)
> > --
> > Traceback (most recent call last):
On 8/13/07, Paul Colomiets <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I see four tests fail that passed yesterday:
> > [...]
> > < test_threaded_import
> Patch attached.
> Need any comments?
Thanks! The patch as-is didn't help, but after changing the write()
line to b'blat' it works.
On 8/13/07, Russell E Owen <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
>
> > Guido van Rossum writes:
> >
> > > However, the old universal newlines feature also set an attibute named
> > > 'newlines' on the file object to a tupl
> So that leaves 1.
Ok. So several people have spoken in favor of removing string.letters;
I'll work on removing it.
Regards,
Martin
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
ht
On 8/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It's official! The second annual Python Sprint @ Google is happening
> again: August 22-25 (Wed-Sat).
I can't attend this year (damn doctor's appt.), but I will try to be
on Google Talk (username of bcannon) in case I can help out somehow
r
Since Python makes such a distinction between statements and expressions, I
am proposing that function calls as statements should be allowed to omit
parentheses. What I am proposing is 100% compatible with Python 2.x's
behavior of function calls; so those uncomfortable with this (basic) idea
can co
Talin wrote:
> I'm not sure that I'm happy with my own syntax proposal just yet. I want
> to sit down with Guido and talk it over before I commit to anything.
>
> I think part of the difficulty that I am having is as follows:
> However, the old syntax doesn't fit very well with the new requir
Eric Smith wrote:
> But the "!" (or
> something similar) is needed, otherwise no format string could ever
> begin with an "r".
My current preference is for 'r' to always mean the
same thing for all types. That means if you're designing
a new format string, you just have to choose something
other
Eric Smith wrote:
> In order for me to write the __format__ function in MyInt, I have to
> know if the specifier is in fact an int specifier.
>
> class MyInt:
> def __format__(self, spec):
> if int.is_int_specifier(spec):
> return int(self).__format__(spec)
>
Eric Smith wrote:
> It's not clear to me if __int__ or __index__ is correct, here. I think
> it's __int__, since float won't have __index__, and we want to be able
> to convert float to int (right?).
This issue doesn't arise if the object itself does the
fallback conversion, as in the example I
Chris Monsanto wrote:
> so those uncomfortable with
> this (basic) idea can continue to use parens in their function calls.
But we would have to read people's code who didn't use them.
> my_func2 # call other function
> my_func2() # call it again
So, those two are the same, but these two are d
Guido van Rossum wrote:
> On 8/13/07, Russell E Owen <[EMAIL PROTECTED]> wrote:
>> In article <[EMAIL PROTECTED]>,
>> "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
>>> I have run into files that intentionally have more than one newline
>>> convention used (mbox and Babyl mail folders, with mess
Hi,
On Monday 13 August 2007 19:51:18 Guido van Rossum wrote:
> Checked in. But next time please do use SF to submit patches (and feel
> free to assign them to me and mail the list about it).
Ah yes, you already asked to use SF. I will use it next time.
> On 8/12/07, Victor Stinner <[EMAIL PROTE
Ron Adam wrote:
> The digits value are number of digits before the decimal. This doesn't
> include the other symbols used in the field so it isn't the same as a field
> width.
How does this work with formats where the number of
digits before the decimal can vary, but before+after
is constant?
I'm working my way through RISCOS code removal. I came across this note in
Misc/HISTORY:
- os.extsep -- a new variable needed by the RISCOS support. It is the
separator used by extensions, and is '.' on all platforms except
RISCOS, where it is '/'. There is no need to use this variable
u
Hi,
After many tests, I'm unable to convert email module to Python 3000. I'm also
unable to take decision of the best type for some contents.
(1) Email parts should be stored as byte or character string?
Related methods: Generator class, Message.get_payload(), Message.as_string().
Let's take
This is a topic for python-ideas, not python-3000.
To be absolutely brutally honest, it doesn't look like you understand
parsing well enough to be able to write a PEP. E.g. why is
cos(3)+4
not interpreted as
cos((3)+4)
in your proposal?
Python's predecessor had something like this, and th
On 8/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'm working my way through RISCOS code removal. I came across this note in
> Misc/HISTORY:
>
> - os.extsep -- a new variable needed by the RISCOS support. It is the
> separator used by extensions, and is '.' on all platforms except
>
>> If RISCOS is going away should os.extsep as well?
Guido> Yes please. It just causes more code for no good reason.
Good. I already removed it in my sandbox. ;-)
While I'm thinking about it, should I be identifying tasks I'm working on
somewhere to avoid duplication of effort? There
Ron Adam wrote:
>
>> :f<+015.5 # Floating point, left aligned, always show sign,
>> # leading zeros, field width 15 (min), 5 decimal places.
>
> Which has precedence... left alignment or zero padding?
>
> Or should this be an error?
The answer is: Just ignore that proposal ent
Use this page: http://wiki.python.org/moin/Py3kToDo
The "master" Python 3000 in the wiki links to these and other
resources: http://wiki.python.org/moin/Python3000
--Guido
On 8/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >> If RISCOS is going away should os.extsep as well?
>
>
Greg Ewing wrote:
> Ron Adam wrote:
>
>> The digits value are number of digits before the decimal. This doesn't
>> include the other symbols used in the field so it isn't the same as a field
>> width.
>
> How does this work with formats where the number of
> digits before the decimal can var
On 8/13/07, Talin <[EMAIL PROTECTED]> wrote:
> So I sat down with Guido and as I expected he has simplified my thoughts
> greatly. Based on the conversation we had, I think we both agree on what
> should be done:
>
>
> 1) There will be a new built-in function "format" that formats a single
> field.
Talin wrote:
> Ron Adam wrote:
>>
>>> :f<+015.5 # Floating point, left aligned, always show sign,
>>> # leading zeros, field width 15 (min), 5 decimal places.
>>
>> Which has precedence... left alignment or zero padding?
>>
>> Or should this be an error?
>
> The answer is: Just
On Mon, 13 Aug 2007 20:53:26 -0700
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
...
> One of my favorite examples of non-numeric types are the date, time
> and datetime types from the datetime module; here I propose that their
> __format__ be defined like this:
>
> def __format__(self, spec):
35 matches
Mail list logo
