Re: [Python-Dev] 2.5.2 release coming up
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 that we should be very careful
> what goes in though -- and we should be paying particular attention to
> stability on all platforms! Fortunately it looks like quite a few 2.5
> buildbots are green: http://python.org/dev/buildbot/2.5/
>
> I propose that anything that ought to go into 2.5.2 (or should be
> reviewed for suitability to go into it) should be marked "urgent" in
> the tracker, *and* have its version set to (or include) "Python 2.5".
I'm not sure if it is particularly urgent because of the rarity of
occurrence, but I discovered a bug that causes httplib to hang
indefinitely given some rarely-occurring input in the wild. To
reproduce:
python -c 'import urllib2; urllib2.urlopen("http://
www.hunteros.com").read()'
WARNING: the page was tagged by one of our users and is definitely NSFW.
Again, it seems to occur very rarely, but the behaviour is quite
painful and the fix trivial (see http://bugs.python.org/issue1966).
Thanks,
-Mike
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Upcoming 2.4.5 and 2.3.7 releases
> 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 standard library > were smaller, and the email package only available separately. It's > also why some of us want a smaller standard library. I see no problem with the email package being maintained in the Python trunk, per se, and I don't think it should be removed from the standard library at all. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slot for __trunc__
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 __trunc__ method only gets called from > the C code for the trunc() function which is currently > implemented with PyObject_CallMethod(number, "__trunc__", "") > instead of a fast call to a slot. I see. Well, it would bounce around a bit but it would never execute Python byte codes. I don't see trunc() being all that performance critical. The cost of adding a new slot is considerable -- for one, *all* type objects become 4 (or 8) bytes longer. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slot for __trunc__
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 code for the trunc() function which is currently > implemented with PyObject_CallMethod(number, "__trunc__", "") > instead of a fast call to a slot. And if __trunc__ qualifies, what about __format__, which is similar? I'm not pushing for it, I just wonder how the decision is made. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slot for __trunc__
[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 currently implemented with PyObject_CallMethod(number, "__trunc__", "") instead of a fast call to a slot. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Slot for __trunc__
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 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:{"__trunc__", (PyCFunction)int_int, METH_NOARGS,
> longobject.c: {"__trunc__", (PyCFunction)long_long, METH_NOARGS,
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Slot for __trunc__
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:{"__trunc__", (PyCFunction)int_int, METH_NOARGS,
longobject.c: {"__trunc__", (PyCFunction)long_long, METH_NOARGS,
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.6 release schedule
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_FillInfo PyObject_ReleaseBuffer PyObject_GetBuffer PyBuffer_ToContiguous PyObject_CheckBuffer PyExc_BufferError Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Upcoming 2.4.5 and 2.3.7 releases
-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 PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR5806HEjvBPtnXfVAQKGTgQAkPUgEssRQOYCEEhAshQcO3hYm7I47Tdk uY1TG7a7hKd0kVksWsRlJCDOHUrxay0EORxf++IJyht+xkSUo50Yq6nAM0cx1xWA mjupkNu4ChwLpvfI+2Q6Haz6Ws30e0M5YtZeH1XJlFXIaPmwF44HEsBmVGxf2EYO ihFY6Xt5M3A= =G22Z -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Upcoming 2.4.5 and 2.3.7 releases
-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. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR58c+nEjvBPtnXfVAQI1XgP/S9YUtkAC/x77alsmBYXtaoGZNrQ/QvtR bziE1zzQ/Luexe9nt41JEaSbVyWb1dw0KZvpoDzqhqbLfhYAXCvJVFIlbw0U94bh pf1G42L3U1YauzzUQL1Q9g0IT4jRMc3D3G8hwX4iOECEW8uHla9uAiqSl5r/V5af K8BcRtkzz0Q= =8tA5 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
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 >> disconnected than most, because often the quoted text is in a >> different thread. > > His mails don't have any indication they're a reply at all - not even > so much as a "Re: " in the Subject. Even Outlook Express isn't *that* > broken; I suspect he's not actually using the 'reply' button in his > mailer. Raymond, I don;t know why everyone's talking about you as though you weren't reading the thread and able to answer questions. Though I *have* sometimes wondered why your posts lack attributions for the quotes. I see from your headers you have, at least some of the time, been posting via gmane using "mirapoint webmail direct", whatever that is. Perhaps that's the problem? sticking-with-t'bird-despite-its-faults-ly y'rs - steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
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.
>>> type(object)
>>> list({1:2, 3:4})
[1, 3]
>>> set({1:2, 3:4})
set([1, 3])
>>>
[...]
Surely the real issue here is that int() grew up purely as a conversion
function, and metamorphosed into a type when the classic classes were
moved into the background.
A brief scan of the 2.4 library (the nearest to hand) shows no uses of
int() without an argument in the top level modules. There's clearly no
point calling int() with a literal integer argument, so its uses for
conversion clearly dominate its use as a pure type constructor.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunc()
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, because often the quoted text is in a > different thread. His mails don't have any indication they're a reply at all - not even so much as a "Re: " in the Subject. Even Outlook Express isn't *that* broken; I suspect he's not actually using the 'reply' button in his mailer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorrect documentation of the raw_input built-in function
-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 from the C. Rationale for Shell and Utilities (XCU). >Otherwise, > > > a message indicating that the >> utility had insufficient memory in which to operate would not be described. > >sounds like an out-of-memory message shouldn't be written to >stderr, which I'm fairly sure is not the case! It's only talking about what will be described in the various sections of the utilities' documentation, yes. But it was the closest I could find to *anything* explicitly mentioning stdin, stdout, or stderr and their function. I could find nothing with regard to prompting or other such descriptions. So, don't count on POSIX to mandate anything on this (as far as I can tell). -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
