Switching to Python 3

[Nick Coghlan]

On 08/03/2012 11:15 PM, tim.lauridsen at gmail.com wrote:
> What is the benefit of using python3 as primary version in Fedora, Other
> than generate at lot of extra work for developers.
> Python3 is just like another language, so you will put
> extra maintenance work on developers who make system tools there is  used
> on long life releases like RHEL, it make it hard to backport bug fixes.
> Python 3 is great and if you make something new in python, it is a good
> choice if then need libraries exists to Python 3, but converting an
> application to be used on both python 2.x and 3.x is a lot of extra work
> without big benefits.

The single biggest practical benefit of Python 3.2 over Python 2.x is
chained exceptions (i.e. if an error occurs in an exception handler,
Python 3 will report *both* exceptions by default, where Python 2 will
only report the broken error handler. Better hope you can fix the error
handler *and* subsequently reproduce the original fault that triggered
it!). I mostly work in 2.6 (for deployment on RHEL 6), and they're the
one thing I genuinely miss from 3.2 that isn't also available in 2.7 or
on PyPI (the changes needed to the exception infrastructure to support
chained exceptions are technically backwards incompatible due to a
change in the scope of the name bindings for caught exceptions, thus
they were not backported before the 2.x series went into maintenance mode).

The 3.x series also tries to minimise unnecessary copying, with many
interfaces returning iterators or views over the original data rather
than copies.

The practical benefits of Python 3.3 are even more obvious, especially
the new Unicode implementation (full Unicode compatibility without
paying the price of making even pure ASCII strings 4 times the size),
the substantially improved exception hierarchy for the OS APIs, the
reduced memory consumption for object-oriented code, the faulthandler
module, access to new POSIX features
(http://docs.python.org/dev/whatsnew/3.3.html#os), caching of filesystem
details in the import machinery to minimise stat call overhead
(drastically increasing the speed of Python imports from network
shares), etc.

Converting applications to work on both Python 2 and 3 often *isn't* a
lot of work. In many cases, Armin Ronacher's python-modernize will (with
the aid of the stdlib's "lib2to3" module and Benjamin Peterson's "six"
compatibility module) automatically convert an existing code base into
one that will run on 2.6, 2.7 and 3.2+ (or, 3.3+ if you decide to rely
on 3.3's reintroduction of support for explicit unicode literals)

Not *all* applications are going to be easy to port (especially those
with intricate dependencies on the Python C API or the broken Python 2
text model), but many should fit fairly easily into the common Python
2/3 language subset.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane