Why do people hesitate to use Python 3?

Question

Python 3 was released in December 2008. A lot of time has passed since then but still today many developers hesitate to use Python 3. Even popular frameworks like Django are not compatible with Python 3 yet but still rely on Python 2.

Sure, Python 3 has some incompatibilities with Python 2 and some people need to rely on backwards-compatibility. But hasn't Python 3 been around long enough now for most projects to switch or start with Python 3?

Having two competing versions has so many drawbacks; two branches need to be maintained, confusion for learners and so on. So why is there so much hesitation throughout the Python community about switching to Python 3?

Answer 1

Note that I'm no longer updating this answer. I have a much longer Python 3 Q & A on my personal site at http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

Previous answer:

(Status update, September 2012)

We (i.e. the Python core developers) predicted when Python 3.0 was released that it would take about 5 years for 3.x to become the "default" choice for new projects over the 2.x series. That prediction is why the planned maintenance period for the 2.7 release is so long.

The original Python 3.0 release also turned out to have some critical issues with poor IO performance that made it effectively unusable for most practical purposes, so it makes more sense to start the timeline from the release of Python 3.1 in late June, 2009. (Those IO performance problems are also the reason why there are no 3.0.z maintenance releases: there's no good reason anyone would want to stick with 3.0 over upgrading to 3.1).

At time of writing (September 2012), that means we're currently a bit over 3 years into the transition process, and that prediction still seems to be on track.

While people typing Python 3 code are most regularly bitten by syntactic changes like print becoming a function, that actually isn't a hassle for library porting because the automated 2to3 conversion tool handles it quite happily.

The biggest problem in practice is actually a semantic one: Python 3 doesn't let you play fast and loose with text encodings the way Python 2 does. This is both its greatest benefit over Python 2, but also the greatest barrier to porting: you have to fix your Unicode handling issues to get a port to work correctly (whereas in 2.x, a lot of that code silently produced incorrect data with non-ASCII inputs, giving the impression of working, especially in environments where non-ASCII data is uncommon).

Even the standard library in Python 3.0 and 3.1 still had Unicode handling issues, making it difficult to port a lot of libraries (especially those related to web services).

3.2 addressed a lot of those problems, providing a much better target for libraries and frameworks like Django. 3.2 also brought the first working version of wsgiref (the main standard used for communication between web servers and web applications written in Python) for 3.x, which was a necessary prerequisite for adoption in the web space.

Key dependencies like NumPy and SciPy have now been ported, installation and dependency management tools like zc.buildout, pip and virtualenv are available for 3.x, the Pyramid 1.3 release supports Python 3.2, the upcoming Django 1.5 release includes experimental Python 3 support, and the 12.0 release of the Twisted networking framework dropped support of Python 2.5 in order to pave the way for creating a Python 3 compatible version.

In addition to progress on Python 3 compatibility libraries and frameworks, the popular JIT-compiled PyPy interpreter implementation is actively working on Python 3 support.

Tools for managing the migration process have also improved markedly. In addition to the 2to3 tool provided as part of CPython (which is now considered best suited for one-time conversions of applications which don't need to maintain support for the 2.x series), there is also python-modernize, which uses the 2to3 infrastructure to target the (large) common subset of Python 2 and Python 3. This tool creates a single code base that will run on both Python 2.6+ and Python 3.2+ with the aid of the six compatibility library. The Python 3.3 release also eliminates one major cause of "noise" when migrating existing Unicode aware applications: Python 3.3 once again supports the 'u' prefix for string literals (it doesn't actually do anything in Python 3 - it's just been restored to avoid inadvertently making migrating to Python 3 harder for users that had already correctly distinguished their text and binary literals in Python 2).

So we're actually pretty happy with how things are progressing - there are still nearly 2 years to go on our original time frame, and the changes are rippling out nicely through the whole Python ecosystem.

Since a lot of projects don't curate their Python Package Index metadata properly, and some projects with less active maintainers have been forked to add Python 3 support, purely automated PyPI scanners still give an overly negative view of the state of the Python 3 library support.

A preferred alternative for obtaining information on the level of Python 3 support on PyPI is http://py3ksupport.appspot.com/

This list is personally curated by Brett Cannon (a long-time Python core developer) to account for incorrect project metadata, Python 3 support which is in source control tools but not yet in an official release, and projects which have more up to date forks or alternatives which support Python 3. In many cases, the libraries that are not yet available on Python 3 are missing key dependencies and/or the lack of Python 3 support in other projects lessens user demand (e.g. once the core Django framework is available on Python 3, related tools like South and django-celery are more likely to add Python 3 support, and the availability of Python 3 support in both Pyramid and Django makes it more likely that Python 3 support will be implemented in other tools like gevent).

The site at http://getpython3.com/ includes some excellent links to books and other resources for Python 3, identifies some key libraries and frameworks that already support Python 3, and also provides some information on how developers can seek financial assistance from the PSF in porting key projects to Python 3.

Another good resource is the community wiki page on factors to consider when choosing a Python version for a new project: http://wiki.python.org/moin/Python2orPython3

Answer 2

I believe that a lot of the hesitation comes from two things:

• If it ain't broke, don't fix it
• [XYZ library] we require doesn't have a 3.0 port

There are quite a few differences to the way the core language behaves, outlined in this document. Something as simple as changing "print" from a statement to a function, for example, will break a lot of Python 2.x code - and that's only the simplest. They got rid of the older-style classes completely in 3.0. They are, in fact, quite different languages - so porting old code is not as simple as some might assume.

Answer 3

There are no compulsive reasons for existing businesses to spend time, money and effort migrating to something while having no change in the existing feature set. I mean to say code base on Python 2 series has been up and running in business for a long time its stable, tested and has all the current product feature set. Why would anybody spend time, money and effort just to move Python 3 just for the sake of migrating to it.

Besides post migration ensuring there are no regression failures and all that headache is unavoidable.

For new projects the policy is plain and simple, it all starts on the following points:

1. Does any distro like Ubuntu ship Python 3 in their default installation?
2. What is the library ecosystem for Python 3.
3. Are all the frameworks et al compatible with Python 3. etc etc.

Its your usual 'choosing a new language' process. This is where the chicken-egg problem comes in, Not many people are using it because not many people are using it. Ultimately nobody feels like moving to it at all.

Breaking backwards compatibility has never been a good thing, at the end of it you always end a good percentage of users.

Answer 4

Around the time Python 2.0 was released, Python was rapidly growing in popularity. There were lots of new users who naturally used the latest version, as they had no dependences on the older versions. With lots of people adopting 2.0 by default, there was a lot of pressure on library developers etc.

By the time Python 3.0 was released, there were already a huge number of users dependent on Python 2.0, and exponential growth (keeping a constant factor relative to existing users) obviously can't be sustained indefinitely.

Personally, the new features back in the Python 2 days seemed a lot more compelling than those provided by Python 3.

I used to think Python 3 would eventually take over anyway, but I'm not so sure now. But it's not just Python that has this issue. After all, how many people honestly use Perl 6? That's been around a fair bit longer than Python 3, IIRC.

Answer 5

A big show stopper for me, which I don't think can be addressed by automatic translation, is integer division. I have scientific codes that rely on x/2 giving x rounded down (when x is integer).

Python 3 wouldn't do that, but would give a .5 answer (for odd x).
I can't just replace all / in my code with // because sometimes I do float division, and so want the float behaviour.

So, for me to port to python 3, I'll have to trawl through tens of thousands of lines of code, checking every /, and seeing if I can figure out whether it should be / or //.

Answer 6

From web services perspective: None of major server frameworks nor web frameworks support Python3.

Update: Obviously that was the case in early 2011, as of now (late 2013), most major frameworks are working with Python3. However some still are not compatible. Significant example would be Twisted, where it's still work in progress.

Answer 7

Python 3 is nice to start a new project if all the libraries you need are ported to Py3k already.

If this is not an option, using Python 2.7 is the best of both worlds: you have most every library created for Python 2.x and you can gradually alter your code to be Py3k-compatible, so that migration is easy when you decide on it. The list of syntax goodies from Py3k you already have in 2.7 is rather long, just don't forget to import from __future__. My favorites are Unicode by default and division always producing a float.

Answer 8

There are no compelling reasons I've seen to use P3K unless you are doing heavy i18n work. In my forays, I've found the pervasive Unicode to be a barrier to my (ASCII) work and the compulsory generators to clog my code.

In a few years, 3 will present a more compelling environment, but, not today.

Answer 9

Distributions don't make Python3 available. There are some fringe distros which already transition off Python2. But mainstream Linux variants like Debian, Ubuntu etc. don't. That's the main reason for me as application author not to do either.

Albeit I prepared the transition and even try to avoid the syntax constructs which have been incompatibilized, I cannot properly test it. It boils down to the chicken and egg problem really.