On 08/03/2012 11:15 PM, tim.lauridsen@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.