Weekly Edition
Return to the Distributions page
| |||||||||||||
Pushing Python3
It has been almost exactly three years since the Python 3.0 release was announced. This
release deliberately broke compatibility with version 2.x of the language,
leaving a lot of old baggage behind with the idea of easing future
development of both Python and programs written in Python. It is fair to
say that Python3 has not yet displaced its predecessor; as can be seen on
the Python3 wall of shame
site, there is still a lot of Python2-only code out there and more continues to
be written. Before writing off Python3 as a failure, though, it is worth
looking at some of the work being done to push the transition to this
version of the language, much of which is happening in the context of
distributions.
The most ambitious Python3 work, arguably, is happening at Ubuntu under the guidance of longtime Python hacker Barry Warsaw. The Ubuntu developers are working to port a number of desktop applications to Python3, with the idea of pushing the necessary changes upstream. If upstream is not receptive to the changes, Ubuntu will do the port regardless:
We want to get upstream package authors and application developers
to support Python 3 as much as possible. I hope there will be no
cases where a distro has to fork a package or application to
support Python 3, although we will do it if there's no other way.
Most likely for Ubuntu though, that would be pushing the changes
into Debian.
The list of specific applications has not been posted anywhere, but the long-term goal has been made quite clear:
Our goal is for the Ubuntu 14.04 LTS release (in April 2014) to
have no Python 2 on the release images, or in our "main" archive,
so everything you'd get on your desktop in a default install would
be Python 3. For the upcoming 12.04 LTS release, I'd be happy if
we had just a couple of Python 3 applications on the desktop by
default.
The other distribution that has done a lot of Python3-related work is Fedora, though, as described by Toshio Kuratomi, the emphasis is a bit different. There is no big push to port specific applications or to set a deadline for pushing Python2 out of the default install. The work, instead, is more low-level:
Unlike Barry's work with Ubuntu, though, we're mostly chiselling
around the edges; we're working at the level where there's a module
that someone needs to run something (or run some optional features
of something) that runs on python3.
The results of this work can be seen on the Fedora Python3 page. The Python3 interpreter itself was added in the Fedora 13 release; since then, work has gone into increasing the number of modules available for developers wanting to work on Python3 applications. Quite a bit of the necessary module support is now in place, but there is also still a long list of modules that have either not been ported to Python3, or that have not yet been packaged for Fedora. In comparison, the Debian Python3 page seems like a desultory effort. There are some reports that Python3 on Gentoo is currently a bit painful to use; Gentoo seems to be short of developers able to work in this area. OpenSUSE packages Python3, but there does not appear to be any public information about an organized push toward a transition there. These distributions, it seems, are mostly waiting to see what happens elsewhere. Distributors can play a major role in the adoption of major new language versions. Some of us still remember the pain caused by Red Hat's slow transition to Python2 many years ago. Nobody can accuse anybody of having acted with undue haste with regard to Python3, but it does seem that some distributors have decided that it is time to make something happen in that area. As that push gains momentum, we may be hearing more about Python3 in the next year or two. (Log in to post comments)
Pushing Python3 Posted Dec 1, 2011 10:48 UTC (Thu) by danielpf (subscriber, #4723) [Link]
All would be much simpler if the language designers would only implement feature breaking capabilities that can be automatically translated from the old version to the new version. The new language version would always come with a translator. With such rules the transition to Python 3 would have been much faster.
Pushing Python3 Posted Dec 1, 2011 12:49 UTC (Thu) by marduk (subscriber, #3831) [Link] I think if they only did the things that were "easy" to translate, then there would unlikely be the need for a Python3... the whole point of Python3 was to get rid of/refactor bad design decisions in Python2, and there doesn't always exist an "easy to translate" way to do that. OTOH, there is the 2to3 tool, so it's not like it didn't come with any tools at all. Personally I think it would have been cool if the Python3 language/interpreter could still run "legacy" python2 code via some sort of indicator such as pragma python2:or perhaps using python2 import legacymodule This would have helped developers transition incrementally to Python3
Pushing Python3 Posted Dec 1, 2011 14:15 UTC (Thu) by zuki (subscriber, #41808) [Link]
> OTOH, there is the 2to3 tool, so it's not like it didn't come with any tools at all.
I have experience with maintaining a python library (http://mdp-toolkit.sf.net) using 2to3 and it's been really easy. Once numpy was ported to python3, this really wasn't a lot of work to keep the codebase clean enough to run without problems after automatic conversion. There certainly are exceptions, but in case of most pure-python packages, developing on the 2.7 line and automatically converting using 2to3 should be a snap (once the dependencies are available, of course).
Add option to cpython2 Posted Dec 1, 2011 20:56 UTC (Thu) by david.a.wheeler (guest, #72896) [Link]
Or conversely, modify CPython 2 so it could run both python 2 and python 3. Python 3 programs could then state one import, and the transition would have been completed years ago.
The BIG FAILURE here was a confusion between Python the language and Python the implementation. If you have to have an incompatible upgrade to the *language*, that has no bearing on what *implements* it.
Add option to cpython2 Posted Dec 1, 2011 23:00 UTC (Thu) by mastro (subscriber, #72665) [Link]
Python 2.6 and 2.7 do support many Python 3 elements. Try:
from __future__ import absolute_import, division, print_function, unicode_literals
But really you shouldn't try to write some py2 in py3 or vice versa code.
As others have stated, the way to go is instead to get a sufficiently clean py2 source code that can be automatically translated by 2to3 (or 3to2 if you prefer) and do parallel releases for every new version of your software.
Pushing Python3 Posted Dec 1, 2011 15:25 UTC (Thu) by Webexcess (subscriber, #197) [Link]
Would've been interesting to have had something about Arch in this article. I believe they've made /usr/bin/python Python3 (which seems crazy me at the present time)
Pushing Python3 Posted Dec 8, 2011 10:39 UTC (Thu) by rogutes (guest, #59996) [Link]
Yes, Arch Linux should have been included. Their announcement is from
2010-10-18: http://www.archlinux.org/news/python-is-now-python-3/
Distribution role Posted Dec 1, 2011 17:55 UTC (Thu) by ballombe (subscriber, #9523) [Link]
> Distributors can play a major role in the adoption of major new language versions.
But should they ? What if the distribution users would prefer to keep support for older versions ?
Distribution role Posted Dec 1, 2011 19:16 UTC (Thu) by smoogen (subscriber, #97) [Link]
Then those users can pay for the maintenance one way or another. Standing still is not zero cost to the distributor as the maintenance or having to support 2 stacks becomes more expensive. Users can pay either by doing the work themselves or paying for some developer to do so.
Pushing Python3 Posted Dec 4, 2011 10:38 UTC (Sun) by grahame (subscriber, #5823) [Link]
I've written this:
https://github.com/grahame/shrubbery
It's a full python 3 stack, from readline all the way to matplotlib, numpy, scipy, PyGTK and the ipython qtconsole (with inline graph support). It's for MacOS X but it's relevant to this discussion because it shows just how far you can get with Python 3 at the moment.
I'd say the big missing things in the Python 3 world are Twisted and Django. Django is looking increasingly old and creaky anyway (try writing anything RESTful/API based in it), so perhaps we'll stop using it before it actually ports to Python 3. Twisted is a big loss though.
I've been using Python 3 exclusively for my spare-time projects for the past year. It's a better language in a number of ways, going back to Python 2 for software I want to ship to people is a depressing experience. Glad to see that the Python 3 situation on Linux looks set to improve!
Python 3 and BIND 10 Posted Dec 6, 2011 20:48 UTC (Tue) by shane (subscriber, #3335) [Link]
We picked Python 3 when we started BIND 10 in April 2009. Our expectation then (and now) is that BIND 10 would take 5 years to complete, and we figured Python 3 would be more-or-less mainstream by the time we are ready for widespread use.
To date, we haven't had any major problems by using Python 3, although to be fair we don't rely on a lot of 3rd party Python libraries. Most of the things we need are in base Python, and the rest are actually specific to our program (DNS libraries and other APIs that we have built).
Which is not to say we have had no problems. Our crypto library, Botan, requires Python 2 to install, which means that if you take a system without Python at all then you need to install Python 2 *and* Python 3 to get BIND 10 installed, at least if you want to build everything from source. Most distributions have a Botan package which makes this problem go away, and patches have been accepted upstream so this should be fixed soon.
Currently a few operating systems don't ship a Python 3 package, but fewer over time. As the article says, distributions are moving in that direction. I am hopeful that in a year or so when we start encouraging the general public to adopt BIND 10 that Python 3 will be a low hurdle for people wanting to try out software that depends on it.
Personally I'm also hoping that PyPy for Python 3 will arrive soon. We don't use Python for speed-critical parts of BIND 10, but "free" performance improvement is always nice. :)
|
|||||||||||||