-----BEGIN PGP SIGNED MESSAGE-----
I'm happy to announce the release of Python 2.6.2 candidate 1. This
release contains dozens of bug fixes since Python 2.6.1. Please see
the NEWS file for a detailed list of changes.
Barring unforeseen problems, Python 2.6.2 final will be released
within a few days.
For more information on Python 2.6 please see
Source tarballs and Windows installers for this release candidate can
be downloaded from the Python 2.6.2 page:
Bugs can be reported in the Python bug tracker:
Python 2.6/3.0 Release Manager
(on behalf of the entire python-dev team)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
-----END PGP SIGNATURE-----
Sadly, my work firewall/proxy often handles things badly, so I can't
actually tell. Is bugs.python.org accepting changes at the moment (I'm
trying to update the Stage of an issue)?
"Don't believe everything you think"
> From: "Cesare Di Mauro" <cesare.dimauro(a)a-tono.com>
> So if Python will generate
> LOAD_CONST 1
> LOAD_CONST 2
> the constant folding code will simply replace them with a single
> LOAD_CONST 3
> When working with such kind of optimizations, the temptation is to
> apply them at any situation possible. For example, in other languages
> a = b * 2 * 3
> will be replaced by
> a = b * 6
> In Python I can't do that, because b can be an object which overloaded
> the * operator, so it *must* be called two times, one for 2 and one for 3.
Not necessarily. For example C/C++ doesn't define the order of the
operations inside an expression (and AFAIK neither Python) and
therefore folding 2 * 3 is OK whether b is an integer or an arbitrary
object with mul operator overloaded. Moreover one would expect * to be
associative and commutative (take a look at Python strings); if a * 2
* 3 returns a different result from a * 6 I will find it very
surprising and probably reject such code.
However you can fix the order of operations like this:
a = (b * 2) * 3
a = b * (2 * 3)
a = b * 2
a = a * 3
There are a couple of ancillary portability concerns due to optimizations which
store system-dependent results of operations between constants in pyc files:
- Issue #5057: code like '\U00012345' is optimized away and its result stored
as a constant in the pyc file, but the result should be different in UCS-2 and
- Issue #5593: code like 1e16+2.9999 is optimized away and its result stored as
a constant (again), but the result can vary slightly depending on the internal
These problems have probably been there for a long time and almost no one seems
to complain, but I thought I'd report them here just in case.
I'm a little confused by the recent changes to the generator system...
I basically agreed with renaming the next() method to __next__(), so as
to follow the naming of other similar methods (__iter__() etc.).
But I noticed then that all the other methods of the generator had
stayed the same (send, throw, close...), which gives really weird (imo)
Browsing the web, I've found people troubled by that asymmetry, but no
remarks on its causes nor its future...
Since __next__(), send() and others have really really close semantics,
I consider that state as a python wart, one of the few real ones I can
Is there any plan to fix this ? Either by coming back to the next()
method, or by putting all the "magical methods" of generators in the
__specialattributes__ bag ?
Thanks a lot for the information,
On Wed, Apr 8, 2009 at 2:24 AM, Heikki Toivonen
> David Cournapeau wrote:
>> The hard (or rather time consuming) work is to do everything else that
>> distutils does related to the packaging. That's where scons/waf are
>> more interesting than cmake IMO, because you can "easily" give up this
>> task back to distutils, whereas it is inherently more difficult with
> I think this was the first I heard about using SCons this way. Do you
> have any articles or examples of this? If not, could you perhaps write one?
I developed numscons as an experiment to build numpy, scipy, and other
complex python projects depending on many library/compilers:
The general ideas are somewhat explained on my blog
And also the slides from SciPy08 conf:
It is plugged into distutils through a scons command (which bypasses
all the compiled build_* ones, so that the whole build is done through
scons for correct dependency handling). It is not really meant as a
general replacement (it is too fragile, partly because of distutils,
partly because of scons, partly because of me), but it shows it is
possible not only theoretically.
It would have helped if I'd copied the list...
2009/4/7 Paul Moore <p.f.moore(a)gmail.com>:
> 2009/4/7 Michael Foord <fuzzyman(a)voidspace.org.uk>:
>> Mark Dickinson wrote:
>>> Discussion points
>>> (1) Any objections to including this into py3k? If there's
>>> controversy, then I guess we'll need a PEP.
>> Big +1
>>> (2) Should other Python implementations (Jython,
>>> IronPython, etc.) be expected to use short float repr, or should
>>> it just be considered an implementation detail of CPython?
>>> I propose the latter, except that all implementations should
>>> be required to satisfy eval(repr(x)) == x for finite floats x.
>> Short float repr should be an implementation detail, so long as
>> eval(repr(x)) == x still holds.
> What he said :-)
just saw that os.defpath for Windows is defined as
Lib/ntpath.py:30:defpath = '.;C:\\bin'
Most Windows machines I saw has no c:\bin directory.
Any reason why it was defined this way ?