I just posted on the tracker a patch which adds extensive documentation
for PEP 3101 to the Python Library Reference. This includes:
str.format()
format()
__format__
Formatter
format string syntax
format specification mini-language
http://bugs.python.org/issue1068
(Eric, my de
Martin v. Löwis schrieb:
>> Agreed, thus my original suggestion of a standalone wrapper executable
>> (or using ctypes).
>
> That doesn't work well, either - how do we get this wrapper onto the
> build slaves? It would work if such wrapper shipped with the
> operating system.
>
>> I just think th
I'm pretty happy where we stand now -- I just squashed the last two
failing tests (test_mailbox and test_oldmailbox). It is 9:30 pm here
and I'm tired, so I'm going to try and get a good night's sleep and do
the release as early as I can tomorrow.
Remember, I'll freeze the branch (not a real lock,
Eric Smith wrote:
> Ron Adam wrote:
>>
>>
>> Eric Smith wrote:
>>> Ron Adam wrote:
> get_field(field_name, args, kwargs, used_args)
> Given a field_name as returned by parse, convert it to an object to
> be formatted. The default version takes strings of the form
> defined in t
On 8/30/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > I'm looking for a volunteer who understands the Decimal class well
> > enough to write a __format__ method for it. It should handle all of the
> > same format specifiers as float.__format__, but it should not use the
> > same impl
Talin wrote:
> I'm looking for a volunteer who understands the Decimal class well
> enough to write a __format__ method for it. It should handle all of the
> same format specifiers as float.__format__, but it should not use the
> same implementation as float (so as to preserve accuracy.)
If no
I'm looking for a volunteer who understands the Decimal class well
enough to write a __format__ method for it. It should handle all of the
same format specifiers as float.__format__, but it should not use the
same implementation as float (so as to preserve accuracy.)
Also, I'm interested in sug
Eric Smith wrote:
> Ron Adam wrote:
>> I wonder if this is splitting things up a bit too finely? If the format
>> function takes a conversion argument, it makes it possible to do
>> everything by overriding format_field.
>>
>> def format_field(self, value, format_spec, conversion):
>>
Ron Adam wrote:
>
>
> Eric Smith wrote:
>> Ron Adam wrote:
get_field(field_name, args, kwargs, used_args)
Given a field_name as returned by parse, convert it to an object to
be formatted. The default version takes strings of the form defined
in the PEP, such as "0[name]" or
Talin wrote:
> Also I wanted to ask: How about making the built-in 'format' function
> have a default value of "" for the second argument? So I can just say:
>
>format(x)
>
> as a synonym for:
>
>str(x)
I implemented this in r57797.
Eric.
Eric Smith wrote:
> Ron Adam wrote:
>>> get_field(field_name, args, kwargs, used_args)
>>> Given a field_name as returned by parse, convert it to an object to
>>> be formatted. The default version takes strings of the form defined
>>> in the PEP, such as "0[name]" or "label.title". It records
On 8/30/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> Hello,
>
> the windows version of py3k suddenly stopped compiling because of an
> extra semicolon in PyException_HEAD: PyObject_HEAD definition already
> ends with a semicolon.
>
> gcc seems more tolerant though...
Sorry, fix on the way
Hello,
the windows version of py3k suddenly stopped compiling because of an
extra semicolon in PyException_HEAD: PyObject_HEAD definition already
ends with a semicolon.
gcc seems more tolerant though...
--
Amaury Forgeot d'Arc
___
Python-3000 mailing
Ron Adam wrote:
>> get_field(field_name, args, kwargs, used_args)
>> Given a field_name as returned by parse, convert it to an object to be
>> formatted. The default version takes strings of the form defined in
>> the PEP, such as "0[name]" or "label.title". It records which args
>> have been
> Agreed, thus my original suggestion of a standalone wrapper executable
> (or using ctypes).
That doesn't work well, either - how do we get this wrapper onto the
build slaves? It would work if such wrapper shipped with the
operating system.
> I just think that if someone needs the functionality
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> However, we can't use pywin32 on the buildbot slaves - it's not
> installed.
Agreed, thus my original suggestion of a standalone wrapper executable
(or using ctypes). But for end users of Python on Windows, this is a
direct Windows-specific API wra
> Tomorrow (Friday August 31) I want to do the 3.0a1 release. I want to
> do it early in the day (US west coast time). It's going to be a
> lightweight release -- I plan to put out a source tarball only, if
> Martin wants to contribute an MSI installer that would be great.
I see what I can do. An
Guido van Rossum wrote:
> Thanks everyone for the large number of improvements that came in this week!
Can I echo this in general? I just lurk here, being fascinated by the
distributed language development process, so I don't have much license
to post and steal precious developer attention. But
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 30, 2007, at 3:00 AM, Neal Norwitz wrote:
> Some of the failures in test_mailbox and test_old_mailbox are the
> same, but I think test_mailbox might have more problems.
It does, and I won't be spending any more time before a1 looking at
it.
Tomorrow (Friday August 31) I want to do the 3.0a1 release. I want to
do it early in the day (US west coast time). It's going to be a
lightweight release -- I plan to put out a source tarball only, if
Martin wants to contribute an MSI installer that would be great. I
plan to lock the tree Friday mo
Neal Norwitz schrieb:
> * On Win64, there's this assert:
>SystemError: Objects\longobject.c:412: bad argument to internal function
> I don't see how it's getting triggered based on the traceback though
Python/getargs.c, line 672:
ival = PyInt_AsSsize_t(arg);
calls Objects/long
Walter Dörwald wrote:
> [...]
> However test_tarfile.py still segfaults for me in the py3k branch. The
> top of the stacktrace is:
>
> #0 0xb7eec07f in memcpy () from /lib/tls/libc.so.6
> #1 0xb7a905bc in s_pack_internal (soself=0xb77dc97c, args=0xb77cddfc,
> offset=0, buf=0x8433c4c "")
>
Guido van Rossum wrote:
> [...[
>
>> * On ia64, test_tarfile.PAXUnicodeTest.test_utf7_filename generates
>> this exception:
>> Objects/exceptions.c:1392: PyUnicodeDecodeError_Create: Assertion
>> `start < 2147483647' failed.
>
> That's probably an uninitialized variable 'startinpos' in one of th
On 8/30/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 8/30/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > I tried recreating the leak with more controllable types, but I haven't
> > > got very far. It seems to be caused by some weird interaction between
> > > io.FileIO, _fileio._Fi
On 8/30/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> There are 6 tests that fail on all platforms AFAIK:
>
> 3 tests failed:
> test_mailbox test_old_mailbox test_unicode_file
> 3 skips unexpected on linux2:
> test_smtplib test_sundry test_ssl
Martin fixed test_unicode_file (I think he may
> For SetErrorMode, if you're just looking for a non-ctypes wrapping,
> it's already covered by pywin32's win32api, which seems simple enough
> to obtain (and likely to already be present) if you're working at this
> level with Win32 calls as a user of Python. Nor is ctypes very
> complicated as a
On 8/30/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>
> On 8/29/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> >
> > Am I the only one seeing a refleak in test_io?
>
> I know of leaks in 4 modules, but they all may point to the same one
> you identified:
>
> test_io leaked [62, 62] references, sum
On 8/30/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > I tried recreating the leak with more controllable types, but I haven't
> > got very far. It seems to be caused by some weird interaction between
> > io.FileIO, _fileio._FileIO and io.IOBase, specifically io.IOBase.__del_
> > _() callin
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> So, an environment variable would be useful, but maybe there should also be
>> a Python function available that calls set_error_mode().
>> sys.set_error_mode()?
>
> Even though this would be somewhat lying - I'd put it into
> msvcrt.set_error_mode
> But unlike Unix, these text messages are guaranteed to be lost.
Not really. We are probably talking about release builds primarily,
where the only such message is the system error (as the assertions
aren't compiled in, anyway). If such an error occurs, the message
is lost - but an error code is
Martin v. Löwis schrieb:
>> So, an environment variable would be useful, but maybe there should also be
>> a Python function available that calls set_error_mode().
>> sys.set_error_mode()?
>
> Even though this would be somewhat lying - I'd put it into
> msvcrt.set_error_mode. For the _CrtSet fun
Martin v. Löwis wrote:
>>> It should still require an environment variable, say
>>> PYTHONNOERRORWINDOW, whether or not it should be considered only
>>> in debug releases, I don't know. One place to put it would be
>>> Modules/main.c (where all the other environment variables are
>>> considered).
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 30, 2007, at 3:00 AM, Neal Norwitz wrote:
> There are 6 tests that fail on all platforms AFAIK:
>
> 3 tests failed:
> test_mailbox test_old_mailbox test_unicode_file
> 3 skips unexpected on linux2:
> test_smtplib test_sundry test_ssl
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 29, 2007, at 11:51 PM, Guido van Rossum wrote:
> On 8/29/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> On Aug 29, 2007, at 11:28 PM, Guido van Rossum wrote:
>>> No, I don't think I can recover the changes. Would it work to just
>>> copy the fi
>> It should still require an environment variable, say
>> PYTHONNOERRORWINDOW, whether or not it should be considered only
>> in debug releases, I don't know. One place to put it would be
>> Modules/main.c (where all the other environment variables are
>> considered).
>
> It should also not be us
Eric Smith wrote:
> One of the things that PEP 3101 deliberately under specifies is the
> Formatter class, leaving decisions up to the implementation. Now that a
> working implementation exists, I think it's reasonable to tighten it up.
>
> I have checked in a Formatter class that specifies t
Martin v. Löwis wrote:
>> New patch (still detects the debug build because the name of the C runtime
>> dll depends on it):
>
> I know it will be difficult to talk you into not using ctypes :-),
> but...
>
> I think this should go into the interpreter code itself. One problem
> with your patch is
Talin wrote:
> Eric Smith wrote:
>> Eric Smith wrote:
>>> Jim Jewett wrote:
>>
but you might want to take inspiration from the "tail" of an
elementtree node, and return the field with the literal next to it as
a single object.
(literal_text, field_name, format_spec, con
> I tried recreating the leak with more controllable types, but I haven't
> got very far. It seems to be caused by some weird interaction between
> io.FileIO, _fileio._FileIO and io.IOBase, specifically io.IOBase.__del_
> _() calling self.close(), and io.FileIO.close() calling
> _fileio._FileIO.clo
> So, an environment variable would be useful, but maybe there should also be
> a Python function available that calls set_error_mode().
> sys.set_error_mode()?
Even though this would be somewhat lying - I'd put it into
msvcrt.set_error_mode. For the _CrtSet functions, one might
expose them as-i
Martin v. Löwis schrieb:
>> New patch (still detects the debug build because the name of the C runtime
>> dll depends on it):
>
> I know it will be difficult to talk you into not using ctypes :-),
> but...
>
> I think this should go into the interpreter code itself. One problem
> with your patch
Eric Smith wrote:
> Eric Smith wrote:
>> Jim Jewett wrote:
>
>>> but you might want to take inspiration from the "tail" of an
>>> elementtree node, and return the field with the literal next to it as
>>> a single object.
>>>
>>> (literal_text, field_name, format_spec, conversion)
>> I think I
> New patch (still detects the debug build because the name of the C runtime
> dll depends on it):
I know it will be difficult to talk you into not using ctypes :-),
but...
I think this should go into the interpreter code itself. One problem
with your patch is that it breaks if Python is build wi
There are 6 tests that fail on all platforms AFAIK:
3 tests failed:
test_mailbox test_old_mailbox test_unicode_file
3 skips unexpected on linux2:
test_smtplib test_sundry test_ssl
I believe test_smtplib, test_sundry fail for the same reason at least
partially. They can't import email.bas
44 matches
Mail list logo
