I do a lot of scientific computing in Python and have had awful experiences with Python 3. We encourage everyone who comes into our lab to work with 2.7 because the libraries are all there. It's true that Numpy and Scipy now build for Python 3, but another key library, PIL, is lost in limbo with no clear timeline for porting last I checked.

The only reason I've used Python 3 at all was because of project involving blender. I needed to do in-memory JPEG compression for quickly streaming images from the game engine. In Python 2, this is a couple lines of code using PIL. Instead, I ended up having to write my own pyjpeg module that provided a ctypes interface to a custom libjpeg-based compression library. I'm proud of the result, but the aggravation and frustration that entailed has removed any desire I have to move to Python 3.

I don't see why the irresponsible maintainership of PIL should reflect badly on Python 3. Pillow is a fork of PIL which was created to address some of these problems:

http://pypi.python.org/pypi/Pillow#why-a-fork

I should clarify that Python 3, by itself, is fine. I had the unfortunate situation of having to use it for a task in which no suitable library existed, which led to a significant amount of unwelcome additional effort. However, until those library deficiencies are fully met, it makes no sense to move forward from 2.7.

Thanks for the Pillow link, btw. I was unaware of it.

For what it's worth, it was intended to be a slow transition (3-5 years) since it's a chicken/egg situation because of backwards compatibility.

The good news is that adoption should pick up very quickly after this fall. Python 3.3 will make it easier to port Python 2 projects and provide more incentives to upgrade. There's also nearly a critical percentage of major packages ported, and Django (which is still on Python 2, and is a deal breaker for many people) will have experimental support for versions up to 3.3.

I expect that by this time next year, the default for most new projects will be Python 3.

agreed. Django is a major reason why adoption hasn't been quicker up to now.

Wait till this fall when we release Django 1.5 :)

Friendly question - What is the reason for the delay, I haven't read much on the reasons why Django doesn't support Python 3 as I have been happy with 2.7 for ages.

To get to Python 3 support, you first have to drop support for Python 2 versions under 2.6, because 2.6 began introducing Python 3 compatibility features that make it possible to run the same code on 2.6/2.7 and on 3.x.

That's basically 90% of the time taken right there, since we had to do it one Python version at a time, giving people warnings that we'd be dropping support for 2.3, then 2.4, etc. so they'd be able to migrate up to a newer Python.

To be fair, Guido laid out a 5 year process for it and we are just over half way. There is actually movement now as libs get moved over.

This is one reason I like to recommend Lutz' book to beginners. Aside from generally being rather decent and thorough, it also teaches Python 3 and how Python 2 differs from it (rather than the other way around, or ignoring Python 3 altogether), resulting in a full, useful education on both, but from the right vantage point.

I like the Lutz's book. I think if there is a version of the book which covers only Python3, that would be a great start for a person who is absolutely newbie to Python. For a Python beginner I think the constant reference/comparison and going back and forth (in the book) between Python 2 and Python 3 would be rather distracting.

One of the issues is that almost every Linux distro is still shipping 2.7+ (and with good reason, there's a lot of code that won't run in 3.0 still).

I think now that 2.7 is the last we will start to see a bit more migrate.

Edit: I didn't mean they aren't shipping 3.0, but that the default is still 2.7.x

That's simply not true, unless perhaps you actually mean "almost every Linux distro" (i.e. including the bulk of distros that have a whole of five users and release once in a blue moon).

The fact is that almost every major distro is shipping Python 3, and often has been for several releases/years: Fedora, Ubuntu, openSUSE, Debian, Gentoo, ArchLinux ... and many of these also have anywhere from dozens to hundreds of Python 3 libraries packaged.

If you mean that /usr/bin/python still points to Python 2 on most of these (in fact all of them except for ArchLinux): True, and that is unlikely to change, possibly never. It's my understanding that this is in keeping with upstream's wishes (from discussions on python-devel and python-porting): bin/python is to remain Python 2 with python3 being the right way to run the Python 3 interpreter.

That's so idiotic, I can't believe it might be the consensus on the python lists. It's exactly the right approach if you want to keep everyone on python 2 forever.

Linux developers and sysadmins are lazy by default (with good reasons: they have a lot to do). To make them get off their arses, you have to switch defaults and scream loudly when stuff breaks, otherwise they'll never bother.

If the problem is that it will break package xyz that is so old and completely unmaintained that nobody can fix it, well, it's a good reason to drop a zombie package. If your code depends on a zombie package, things would have broken down sooner or later anyway.

Sorry, you are right, I did mean that /usr/bin/python is usually 2.7.

For someone just starting out with python (on linux anyways) that means they are probably going to fire up that interpreter first.

I was wondering myself actually if any of the distros would switch to 3.0. I think a lot of packages would break if that were to happen.

As you've said, Arch has already switched but their package release isn't really typical for most distros.

Ubuntu's Python maintainer Barry Warsaw recently announced their goal to have no Python 2 in the "main" part of the repositories by their April 2014 release: http://lwn.net/Articles/469939/

I think that's probably a too aggressive schedule to actually keep, but here's hoping.

I'm curious if a distribution like RedHat will ever link /usr/bin/python to python3 instead of python2, the way Arch did. Arch gets away with it because it's a bleeding-edge rolling-release distro, but a distro like CentOS that prides itself on stability has much more to lose. This is the only real point of uncertainty, if you ask me.

I think they won't, that it's no longer a point of uncertainty, and that Arch essentially made a mistake in switching their /usr/bin/python prematurely.

The consensus from Python list discussions like "Shebang lines for Python 3" and "Support the /usr/bin/python2 symlink upstream" seemed to be that /usr/bin/python is to remain Python 2 indefinitely and that newly-written scripts should call python2 or python3 explicitly. If I recall right Guido's stance was the latter, but leaving plain python up to distros.

There's also PEP 394: http://www.python.org/dev/peps/pep-0394/

This is further cemented, if you will, by the new Windows launcher in 3.3 that extends shebang support to that platform and supports the same mappings.

That said, one of the KDE applications I maintain contains a fair amount of Python code, and since I consider Python 3 to be a much nicer language, it of course runs fine on 3.x. And purely from an emotional POV the fact that the Arch packages get to install those scripts without their usual sed call to replace "python" with "python2" does bring a smile to my face.

Arch moved to python3 well over a year ago.

Python2 is still in base-devel, but /usr/bin/python symlinks to python3, not python2.

You are right, I remember seeing that on my laptop.

Can you blame them? It's what experienced Python developers are using in the real world and there are orders of magnitude more tutorials for Python 2.

adoption hasn't seemed slower than reasonable to me. there's been steady progress in porting packages over to it, and until the packages you need are there there isn't much point in using python3.