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?

  • 3
    Are there really so many new projects starting using Python 2? Or is it just long-established projects like Django? Commented Mar 31, 2011 at 8:37
  • 3
    Can you cite some of the discussions/sources? Commented Mar 31, 2011 at 11:28
  • 12
    @Michael Easter - He doesn't have to. Just check the python tag on SO; a lot of people up there are of the opinion "learn 2.x, 3.x is not ready yet".
    – Rook
    Commented Mar 31, 2011 at 11:46
  • 5
    Have you not seen the Python 3 Wall of Shame?
    – detly
    Commented Sep 5, 2012 at 3:49
  • 7
    @detly, it's now call Python 3 Wall of Superpower Commented Mar 4, 2015 at 6:25

9 Answers 9


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

  • 3
    Updated based on the progress over the last 18 months (and explicitly noted the fact that 3.1 was the first real production-viable 3.x release due to the abysmal IO performance in 3.0)
    – ncoghlan
    Commented Sep 5, 2012 at 3:15
  • 1
    To a degree (i.e. we knew it was significantly slower than the io subsystem in 2.6), but the impact on general usability was far worse than we anticipated (our IO benchmarks have improved markedly since then, so there's no chance of something like that being shipped today)
    – ncoghlan
    Commented Oct 30, 2013 at 2:14
  • 6
    Proposed time frame doesn't seem so enthusiastic now in 2015 :|
    – zetah
    Commented Mar 3, 2015 at 13:07
  • 2
    The way I see it (and I will be burned at the stake by some for this) is that on the encoding front, Py3 violated (and still does, as this things go) the Zen of Python in the "pragmatism beats purity" point: Py3 is encoding-pure. Py2 was encoding-pragmatic. Commented Nov 25, 2015 at 22:13
  • 3
    Py3 is still pragmatic about encodings (otherwise we wouldn't have surrogateescape), we just encounter a lot of *nix users that aren't interested in hearing about the way operating system interfaces work on platforms like Windows, .NET and the JVM (including Android). I've written more on that at developerblog.redhat.com/2014/09/09/… The main impact has been on the "errors should not pass silently" front, as we changed data dependent bugs that produced mojibake into structural type errors complaining about mixing binary data and text data.
    – ncoghlan
    Commented Dec 9, 2015 at 7:45

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.

  • 2
    The dependency-doesn't-have-a-port issue is recursive, as well. What's needed is for widely used libraries that have few or no dependencies outside the stdlib to port, which can then start a chain reaction.
    – Tony Meyer
    Commented Mar 31, 2011 at 9:45
  • 12
    I'd switch the order. A lot of us are pacing around, waiting for a particular package to migrate to 3.
    – S.Lott
    Commented Mar 31, 2011 at 10:00
  • 1
    @Tony - that's why I think it's a great boon for 3.0 that Numpy is now available for it. @S.Lott - I guess it really depends on if 3 offers something you want. To be honest, I only very recently moved from 2.5 up to 2.7 - so I'm not really one of those people who follows the "latest and greatest".
    – TZHX
    Commented Mar 31, 2011 at 10:08
  • 1
    Porting old code with the aid of 2to3 isn't as hard as some people fear, either, though.
    – ncoghlan
    Commented Mar 31, 2011 at 12:56
  • 6
    It doesn't help that just about every OS that bundles Python into the distro (OSX, Linux, etc) is still stuck on some ancient version of Python 2. Why write for Python 3 when no-one can use your code without mucking about with the internals of their OS?
    – Ant
    Commented Mar 31, 2011 at 14:18

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.


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.

  • 3
    Hell, I'm still using Fortran77. :) And most of the real "features" from Python 3 have been backported into 2.6 and 2.7, without as many compatibility issues. The only thing Python 3 really offers is a "cleaner" syntax.
    – TZHX
    Commented Mar 31, 2011 at 9:00
  • 3
    Comparing Python 3 and Perl 6 is wrong. Python 3 is a incremental jump from Python 2 whereas Perl 6 is a total ground up redesign. Perl 5 and Perl 6 are sister languages and will continue to co exist for a long time. On the other hand, Python 3 plans to replace Python 2 ,not just co exist. This is a big difference.
    – kamaal
    Commented Mar 31, 2011 at 9:13
  • 1
    Perl 6 is still under development. Yes, Rakudo Perl is the closest implementation to the Perl 6 specification but doesn't implement everything yet. There is simply no production ready Perl 6 implementation yet.
    – Htbaa
    Commented Mar 31, 2011 at 9:14
  • 1
    @Htbaa for many definitions of completeness and readiness. Perl 6 is complete and production ready. The thing is it might take a while to match the complete spec, there are similar things with other languages too. For example GCC even until recently didn't quite really match the entire C++ specification. Language design and implementation is a very slow process.
    – kamaal
    Commented Mar 31, 2011 at 9:22
  • 1
    rakudo.org/node/75 Rakudo star was released long back. You need to try it.
    – kamaal
    Commented Mar 31, 2011 at 10:03

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 //.

  • 8
    The "-Q" option (2.2 to 2.7) can raise warnings for division. Also, fixdiv.py uses these warnings to update the expressions in your scripts.
    – Eryk Sun
    Commented May 17, 2012 at 13:45

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.


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.

  • BTW, Django has just started to experimentally support Python3, in v 1.5.
    – 9000
    Commented Jan 21, 2013 at 8:31
  • 1
    Django 1.6 now officially supports Python 3. Flask also supports it.
    – chhantyal
    Commented Nov 9, 2013 at 19:30

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.


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.

  • 5
    This may have been true once, but "apt-get install python3" and "yum install python3" have both worked for a long time. Tools like tox and services like Shining Panda CI make it straighforward to test across multiple Python versions.
    – ncoghlan
    Commented Nov 29, 2012 at 6:47
  • 1
    Now many of these distros install python3 by default, unlike many other programming languages. Commented Mar 21, 2015 at 6:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.