Python 3 (was Re: Anelok: next round of case parts 1/2: fixing issues)

Paul Boddie paul at
Sun Jan 25 13:59:38 UTC 2015

On Sunday 25. January 2015 10.07.34 Elena ``of Valhalla'' wrote:
> On 2015-01-25 at 02:56:43 -0300, Werner Almesberger wrote:
> > Bas Wijnen wrote:
> > > If you want to be future-proof, you probably want to use python3, in
> > > which 3/2 == 1.5 (and 4/2 == 2.0, not 2); you have to specify integer
> > > division explicitly as 3//2 there.
> > 
> > Oooh, that explains everything. That's a pretty fundamental change to
> > make in a widely deployed language.
> > [...]
> > Hmm, just saw that they removed (converted) the print statement in
> > version 3. And I thought the gcc folks were reckless ;-)

Where have you been, Werner?! Python 3.0 came out in 2008. :-)

> Python 3.0 was designed explicitely to allow for fundamental changes
> that broke compatibility: in a way it can be considered almost a
> (close) derivative of python 2.x rather than a version of the same
> language.
> Some changes were however backported to python2 and it is possible to
> write at least some code that is able to run under both 2 and 3
> by importing the relevant changes from __future__; it is the first
> approach listed on

Python 2.7 is pretty much the recommended vehicle for moving off Python 2 and 
onto Python 3, although Python 2.6 was the first release where this was 
considered viable. And in fact, Python 2.6 introduced some performance 
regressions that may have been due to the compatibility features added 
specially for Python 3 porting purposes. Even now, you can be unlucky and have 
whining stderr messages about Python 3 incompatibility produced by libraries 
imported by your Python 2 programs, which could be regarded as a form of 
filling people's logs out of spite for them not having incurred the cost of 
porting their software to Python 3.

> You can use just the new division behaviour by importing ``division``
> from __future__, or you can import all of the four modules and
> try to keep the code running under both versions.

"Future" division was introduced before Python 3.0 came about, and in fact 
brought about the __future__ mechanism of supposedly graceful change within 
the Python 2.x series. The idea was that such incremental changes would very 
slowly lead to the mythical "Python 3000" - a fixed-up and more elegant 
version of Python - but when the core developers realised that they had the 
time to push for Python 3000 in the near term, the discontinuity between 
Python 2 and the newly-created Python 3 came about.

I'm not a fan of what they did with Python 3, even if it could be said to be a 
better language. On the topic of CAD and modelling, I believe the Blender 
project experienced a degree of inconvenience after being persuaded to be 
Python 3 early adopters. And the whole business has just created confusion and 
fragmentation (and a degree of hostility towards anyone who doesn't 
unconditionally advocate Python 3 adoption).

Having now acquainted Werner with Python 3, perhaps we shouldn't mention the 
latest core developer push for type annotations in Python. :-)


More information about the discussion mailing list