On 22-Jan-08, at 8:47 PM, Guido van Rossum wrote:
> While the exact release schedule for 2.5.2 is still up in the air, I
> expect that it will be within a few weeks. This means that we need to
> make sure that anything that should go into 2.5.2 goes in ASAP,
> preferably this week. It also means t
> Releasing the email package from the Python maintenance branches is
> probably insane.
People seem to use a lot of strong language lately.
>From m-w.com:
insane (adjective)
1. mentally disordered
3. absurd == ridiculously unreasonable
> This kind of thing would be less of a problem if the st
On Jan 29, 2008 11:34 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [GvR]
> > I don't see why. __index__ has a slot because its
> > primary use is to be called from C code, where slots
> > add a slight performance advantage.
> > __trunc__ doesn't get called from C AFAIK.
>
> I thought the __tr
Raymond Hettinger wrote:
> [GvR]
>> I don't see why. __index__ has a slot because its
>> primary use is to be called from C code, where slots
>> add a slight performance advantage.
>> __trunc__ doesn't get called from C AFAIK.
>
> I thought the __trunc__ method only gets called from
> the C cod
[GvR]
> I don't see why. __index__ has a slot because its
> primary use is to be called from C code, where slots
> add a slight performance advantage.
> __trunc__ doesn't get called from C AFAIK.
I thought the __trunc__ method only gets called from
the C code for the trunc() function which is c
I don't see why. __index__ has a slot because its primary use is to be
called from C code, where slots add a slight performance advantage.
__trunc__ doesn't get called from C AFAIK.
On Jan 29, 2008 11:04 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Should the implementation of __trunc__ have
Should the implementation of __trunc__ have its own slot like we have for
nb_index?
Raymond
---
[EMAIL PROTECTED] ~/py26/Objects $ grep "__trunc__" *.c
floatobject.c: {"__trunc__", (PyCFunction)float_trunc, METH_NOARGS,
intobject.c:{"__
Travis E. Oliphant wrote:
> Yes, I will. What are your time-lines? I've been targeting first week
> in March.
I like to port bytearray to 2.6 as early as possible. I'd be grateful if
you could port a limited subset of the new buffer protocol within the
next few weeks. bytearray needs:
PyBuffer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2008, at 1:01 AM, Martin v. Löwis wrote:
>> What do you think of the above?
>
> Sounds fine to me. I won't touch this then for the moment,
> please let me know when you are done rearranging things.
All done! Thanks.
- -Barry
-BEGIN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 29, 2008, at 1:01 AM, Martin v. Löwis wrote:
>> What do you think of the above?
>
> Sounds fine to me. I won't touch this then for the moment,
> please let me know when you are done rearranging things.
Cool, I'll try to get to this today.
- -B
Jon Ribbens wrote:
> On Mon, Jan 28, 2008 at 08:07:21PM -0800, Guido van Rossum wrote:
>> PS. There's something wrong with Raymond's mailer that creates a
>> thread in gmail whenever he responds. I suspect it's not correctly
>> adding an In-reply-to header. That makes the thread feel much more
>> d
Jeffrey Yasskin wrote:
[...]
> Just like set(sequence) is the set associated with that sequence, not
> the set part of that sequence, and float('3.14') is the float
> associated with '3.14', not the float part of '3.14', etc. Type names
> do not normally retrieve pieces of other objects.
>>> typ
On Mon, Jan 28, 2008 at 08:07:21PM -0800, Guido van Rossum wrote:
> PS. There's something wrong with Raymond's mailer that creates a
> thread in gmail whenever he responds. I suspect it's not correctly
> adding an In-reply-to header. That makes the thread feel much more
> disconnected than most, be
-On [20080129 00:13], Greg Ewing ([EMAIL PROTECTED]) wrote:
>What document did this come from? This sounds more like it's
>talking about what should be described in various sections of
>a man page, not what should be written to the various streams
>by a program.
It did, it's
14 matches
Mail list logo
