Neal Norwitz wrote:
> On 8/18/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>> In preparation for the sprints, I have converted all Python objects to
>> use the new buffer protocol PEP and implemented most of the C-API. This
>> work took place in the py3k-buffer branch which now passes all the
Having squashed the final issues, we are now ready to switch over to
the new tracker! The plan is to do it on the 23rd. But before I
announce to the community I wanted to make sure there was not some
specific objection by python-dev or python-3000. If there is please
let me know by midday Monday
On 8/20/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
>
> > Memory leaked when allocated from:
> > array_buffer_getbuf (arraymodule.c:1775)
> > buffer_getbuf (bufferobject.c:28)
> > bytes_init (bytesobject.c:807)
> > type_call (typeobject.c:429)
>
> Hmm. I'm not sure what memory is being l
On 8/19/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 8/19/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > On 8/19/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > > I just fixed a bug in the new memoryview that used PyObject_DEL which
> > > caused a problem in debug mode. I had to change it to
On 8/19/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > Wow, excellent feedback. I've added your email to the list of reminders
> > for the next round of edits.
>
> Here's something else for future edits:
>
> 1. When converting a string to an integer, what should the rules be?
> Should
If one of these pairs exists solely for backwards compatibility, yes.
I think Neal Norwitz started a discussion of a similar issue.
On 8/18/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 8/18/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I'm soliciting ideas for things that need to be done f
Guido van Rossum wrote:
> On 8/19/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> Talin wrote:
>>> Wow, excellent feedback. I've added your email to the list of reminders
>>> for the next round of edits.
>> Here's something else for future edits:
>>
>> 1. When converting a string to an integer, what s
On 8/20/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 8/19/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> >> Talin wrote:
> >>> Wow, excellent feedback. I've added your email to the list of reminders
> >>> for the next round of edits.
> >> Here's something else for future
Guido van Rossum wrote:
>> Converting to strings doesn't really buy you much, since we have the !s
>> specifier. But I think it's needed for backward compatibility with %
>> formatting.
>
> Why? The conversion code can just generate !s:-20 instead of :-20s.
True enough. I'll take it out, too.
T
I'm basically done with format(), string.format(), object.__format__(),
string.__format__(), long.__format__(), and float.__format__(). I have
some cleanup left to do from all of the refactoring, but it's passing
the vast majority of my tests.
The only real remaining work is to implement strin
Eric Smith wrote:
> Guido van Rossum wrote:
>
> > Why? The conversion code can just generate !s:-20 instead of :-20s.
>
> Talin: On your list of to-do items for the PEP, could you add that the
> only conversions for the standard conversion specifiers are int <-> float?
Please, no! While the c
On 8/20/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> I'm basically done with format(), string.format(), object.__format__(),
> string.__format__(), long.__format__(), and float.__format__(). I have
> some cleanup left to do from all of the refactoring, but it's passing
> the vast majority of my tes
On 8/20/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Eric Smith wrote:
> > Guido van Rossum wrote:
> >
> > > Why? The conversion code can just generate !s:-20 instead of :-20s.
> >
> > Talin: On your list of to-do items for the PEP, could you add that the
> > only conversions for the standard conve
Guido van Rossum wrote:
> On 8/20/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>> Modules/Setup.dist contains this comment:
>> # This only contains the minimal set of modules required to run the
>> # setup.py script in the root of the Python source tree.
>>
>> I think this applies to me, as setup.py
On 8/20/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 8/20/07, Eric Smith <[EMAIL PROTECTED]> wrote:
>
> >> Modules/Setup.dist contains this comment:
> >> # This only contains the minimal set of modules required to run the
> >> # setup.py script in the root of the Pytho
Guido van Rossum wrote:
> Hm, those damn dependencies. In that case I suggest adding it to sys
> instead of creating a new internal method. It could be
> sys._formatparser or whatever useful name you'd like to give it, as
> long as it starts with an underscore. That should solve it.
Okay, that's m
Guido van Rossum wrote:
> But how often will you need this? (You only need the !s part if you
> don't know that the argument is a string.)
Maybe I'm confused. I thought we had agreed that most
types would delegate to str if they didn't understand
the format, so most of the time there wouldn't be a
I've completed most of the implementation for PEP 3101. The only thing
I have left to do is the Formatter class, which is supposed to live in
the string module.
My plan is to write this part in Python, and put it in Lib/string.py.
Given the complexities and book-keeping involved, writing it in C
BJörn Lindqvist schrieb:
> It is fantastic! Totally super work. I just have one small request;
> pretty please do not set the font. I'm very happy with my browsers
> default (Verdana), and Bitstream Vera Sans renders badly for me.
Okay, I've changed the stylesheet, it should go live on docs.python
19 matches
Mail list logo
