Mailman 3 January 2008 - Python-Dev

2.5.2 release coming up
by Guido van Rossum 30 Jan '08

30 Jan '08

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". Also, *nothing* should go into the 2.4 branch any more *except* important security patches. If we're doing a security release, it'll most likely be a source-only release, and it will differ from 2.4.4 only in that it will have some new security patches defined. A reminder: 2.5.2 should only get bugfixes, new features. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

10 14

Re: [Python-Dev] Slot for __trunc__
by Raymond Hettinger 30 Jan '08

30 Jan '08

[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

3 2

Slot for __trunc__
by Raymond Hettinger 30 Jan '08

30 Jan '08

Should the implementation of __trunc__ have its own slot like we have for nb_index? Raymond ------------------------------------------------------- rhettinger@localhost ~/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,

2 1

Py2.6 release schedule
by Raymond Hettinger 29 Jan '08

29 Jan '08

What is the current thinking on this? Is the target still April 2008 as mentioned in PEP361? Are we going to have an alpha sometime soonish? Raymond

4 4

trunc()
by Raymond Hettinger 29 Jan '08

29 Jan '08

[Terry Reedy] > For one data point, I asked my bright 13-year-old for the 'integer part' of > 3.1, 3.9, -3.1, and -3.9 and got the expected 3,3,-3,-3 (as with int()). > But asking 'truncate' the same numbers or even 'truncate toward zero' got a > blank stare, which did not surprise me too much as it is not a common > (American) English word. Even to adults, the word has other meanings: http://en.wikipedia.org/wiki/Truncation_%28disambiguation%29 Raymond

4 4

trunc()
by Raymond Hettinger 29 Jan '08

29 Jan '08

[Raymond Hettinger] > Since something similar is happening to math.ceil and math.floor, > I'm curious why trunc() ended-up in builtins instead of the math > module. Doesn't it make sense to collect similar functions > with similar signatures in the same place? [Christian Heimes] > Traditionally the math module is a tiny wrapper around the > system's libm. Functions for magic hooks like __trunc__ > usually end up in builtins. In this particular case I don't > mind where the function is going to live. Traditions have gone out the window. ceil() and floor() are going to have their signatures changed (Real --> Integral) and are going to have their own magic methods. They cannot be characterized as a thin wrapper around libm. So the question stands, why is trunc() different? Can anything good come from having trunc() and int() in the same namespace? Raymond

22 58

Incorrect documentation of the raw_input built-in function
by Mike Kent 29 Jan '08

29 Jan '08

Recently I was trying to debug an old python program who's maintenance I inherited. I was using the quick-and-dirty method of putting some 'print >>sys.stderr' statements in the code, and then running the command with '2>filename' appended to the end of the command line. Imagine my surprise to see that all of the prompt text from the program's raw_input calls were also disappearing from the screen output, and appearing in the stderr output routed to the file. The latest documentation for raw_input states "If the prompt argument is present, it is written to standard output without a trailing newline." I posted a question regarding the observed behavior to comp.lang.python and Gabriel Genellina (thanks Gabriel!) pointed out that despite the documentation, raw_input was hard-coded to always output its prompt text to stderr. This raises two questions: 1. Shouldn't the current documentation be corrected to state that raw_input writes its prompt to standard error? 2. Is this really the hard-coded behavior we want? I don't think my use-case is that odd; in fact, what I find very odd is that the prompt output is send to stderr. I mean, I'm printing the prompt for a question, not some error message. Can there not at least be an optional parameter to indicate that you want the output sent to stdout rather than stderr?

10 21

Re: [Python-Dev] functions vs methods (was Re: trunc())
by Raymond Hettinger 29 Jan '08

29 Jan '08

Please ignore my last email. The idea for combining trunc, ceil, floor, etc was probably just a distractor. [GvR] > One thing I'm beginning to feel more and more strongly about > is that round, trunc, ceil and floor all belong in the same > category, and either should all be builtins or should all > be in math. +1 for all four going into the math module. > I should also admit that the 2-arg version of round() was > borrowed from ABC, but the use case for it there doesn't map > to Python: in ABC it's the only tool you have for floating point > formatting on output, while in Python the same thing would > typically be done with "%.2f" % x rather than round(x, 2). +1 for deprecating the second argument to round(). Raymond

2 1

Announcing the Python core sprint at PyCon 2008
by Brett Cannon 29 Jan '08

29 Jan '08

As has occurred since the inception of PyCon, there will be a sprint on the Python core at this year's conference! If you will be attending PyCon (or will be in Chicago during the dates of the sprints), attending the sprint is a great way to give back to Python. Working on Python itself tends to deepens one knowledge of the language and the standard library. Plus it is just plain fun getting to sit around some tables with fellow Python programmers for several days (the sprint will last four days, but you do not need to attend all four days to participate). The sprint is open to everyone of all skill levels. We can always use help with things from updating documentation to preparing for the next release of Python 3.0. On Sunday evening of the conference there will not only be a sprint intro session, but also a tutorial on how to develop for Python. Details will be covered from where to look in the code base for things to some best practices tips. If you are interested enough to want to sign up to attend, please go to http://wiki.python.org/moin/PyCon2008/SprintSignups/Python and add your name and email address. If you have questions you may email me. Please sign up for the sprint by the end of February as an email on what you need to do beforehand will be sent at that time based on the sprint sign-up page. And if you are not attending PyCon, we will most likely have several people in attendance on IRC, thus allowing even people not at PyCon to participate! -Brett Cannon Python core sprint coach, PyCon 2008

1 0

Re: [Python-Dev] [python] Re: functions vs methods (was Re: trunc())
by Michael Foord 29 Jan '08

29 Jan '08

Raymond Hettinger wrote: [snip..] P.S. One place to attach the constants is to the function object, so we would write: x = round(3.1) # ROUND_TO_EVEN x = round(3.1, round.CEIL) . . . Or Python could gain a first class enumeration structure, a type which has proved useful in other languages. ;-) Michael Foord _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.… -- http://www.manning.com/foord http://www.voidspace.org.uk http://www.ironpython.info

1 0