Updated Packages – Python 3.3

It was not a rejection. Python 3 (project name Python 3000, just to give you the kind of scope we're talking about) was always expected to be a long and rather arduous migration, because it "cleaned up" a number of things in backwards-incompatible manner: the stdlib was reorganized, syntax was added (and removed), semantics altered (the basic string of Python 2 is a bytestring, in Python 3 it's a codepoint sequence and implicit conversions were removed from the language), shuffling between keywords and regular symbols, etc... It might have been even more arduous than the core team expected, but most of the community has been aware it'd take a long time from the start (the initial planning alone took ~30 months: the PEP3000 was created in April 2006 and Python 3.0 was released in December 2008, and as far as I remember Python 3.0 was not considered a production-able Python, more of a "stable" version for experiments and discovery in real-world settings)

Things were moving very slowly at the start, some features were backported to Python 2, others were reintroduced (in Python 3.2 and 3.3) and compatibility packages slowly appeared as people started experimenting with porting strategies and methods.

Since the second half of 2012, things have started picking up steam as bigger packages have started their migration effort (often as single-source, which is now considered the best strategy when possible) which is starting to solve the chicken-and-eggs problem for end-users (applications can't switch until all their dependencies are compatible)[0].

Python 2 will stick around though, there are 20 years of Python code which won't run as-is on Python 3, and may never do barring significant rewrite.

And of course Python 3 may yet be rejected by the community, although it definitely seems to be gaining — rather than losing — steam. The biggest problems in the long term will probably be in the Scientific Python communities.

[0] A few pretty big names are still Python 2 though, Werkzeug and Flask are big ones for webby stuff, the official-ish MySQL adapter is an other one for many, and a bunch are not considered "production-ready" state or side-packages are missing e.g. Django 1.5 is the start of Django's transition but many extensions such as South or the debug-toolbar are not p3-compatible.

As a Rubyist it also seemed strange to me. As soon as Ruby 1.9 became stable, it was embraced by the community fairly quickly. Ruby 2.0 has only been out for a month and there are already projects that require 2.0. In contrast, Python 3 adoption still isn't finished, and Python 3 has been around for several years longer than Ruby 1.9.

I guess that the incompatible changes in Python 3 don't really help. Ruby 1.9 introduced incompatibilities but they were fairly minor and easy to resolve. The biggest incompatibility was probably the introduction of string encodings. Python 3 introduced a stricter string encoding system and changed syntax in some ways. Some of the syntax changes make it very difficult to write code that is compatible with 2.6, 2.7 and 3.0.

All code WAS written for 2.X, because 3 was either not around yet, under constantly changing flux (before release proper, and to a certain extent for a couple of versions) or the subsequent killer: Not enough libraries that you might depend on, worked in 3.0 yet - as it was written to be deliberately incompatible by removing legacy and old ways of doing things.

IIRC most of the big packages have finally moved over so it'll just become less of an issue over time.

The best thing about python 3 is that it froze python 2. So right now we have this rock solidly stable python (2.7) and this weird new python (3.x) that not a lot of libraries work with. The point here is that they changed too much in python 3. Basic things like division changed, and many of these changes people disagreed with. People will still be starting projects with 2.7 in 5 years.

I don't think it's about "rejection" but a practical thing.

When starting a project you may need some 3rd party stuff (library, framework, etc) that doesn't support Python 3 (yet; for different reasons, sometimes the project is unmaintained, sometimes is a _huge_ project and Python 3 support is not ready, but I have yet to find a project that "rejects" Python 3).

Because 2.x (2.6 to 2.7) is available, it's not a big deal and you just use Python 2. Thanks to 2.7 (that includes several features from Python 3), finally moving to Python 3 shouldn't be a pain for most people, once all your requirements support Python 3.

Can't shed any light on this, just wanted to add a 'me too'. As a perl veteran, I've been meaning to learn Python someday, and I figured I'd wait until the 'new' one became the standard, saving me from worrying about all the random incompatibilities. Maybe I'll only have to wait a few more years!

...makes me wonder if anyone had the opposite thought: A python programmer thinking of learning perl, but waiting until this newfangled perl 6 became the standard. I wonder who'll end up learning a new language first?

Tons of changes in 3 making it backwards incompatible + nearly 20 years of legacy Python libraries

It's not exactly rejected by the community - apart from a few vocal critics, I think most people are comfortable with it, and a lot of code does now support it.

It's just a slow movement, because there's a lot of legacy code out there. Also, many features up to 3.2 were backported to 2.7, so there was little incentive to make the switch. That's starting to change with 3.3.

Well, nothing new. In Java a lot of code is still written for Java 6. C++11 is not even fully supported from compilers And Windows Xp still have more than 30% of market share.

Not easy to port pyGTK projects at all -- they didn't release until long after python 3's first release, and also combined the bump with a step to GTK3 and a different technology for the langauage bindings (gobject-introspections).

Sure, all those three new things are better, but each of them add up to porting a complex app.

Python 2 and Python 3 are effectively different languages in the way that VB and C# are different languages. Does it seem strange that some people code in VB when C# exists?

Python 3 isn't just a little bit incompatible in a few places, it has widespread incompatibilities and is therefore effectively a different language.

Yep, after the feature freeze between 3.1 and 3.2, 3.3 was a significant jump forward.

I'm guessing that Debian, if they have not already done it, will start searching packages for ^#/usr/bin/python$, and filing bug reports for packages that match. So that should not be as much of a problem.

As for user-created scripts...

Nothing will break (in the sense you mention). Python 2 will remain /usr/bin/python while Python 3 is /usr/bin/python3.

If you want to live in the past, don't upgrade.

If you want have your cake and eat it too, tough.

Everyone else, will upgrade and rejoice that Ubuntu isn't 10 years behind like another CrimsonCap distro.

This is different than the Ubuntu proposal. Fedora is not yet shipping Python3 as the default Python interpreter [1].

[1] https://fedoraproject.org/wiki/Python3

Fedora is more of a bleeding-edge (or at least developer-focused) distro - they also ship with Ruby 1.9 instead of 1.8.

Let's hope so, there's got to be a tipping point.

Perl 6 is a different language from Perl 5, and both are being developed actively. Perl 5 was at version 15, last I checked.

Python 2 is not being developed actively, aside from security updates, so it is permanently frozen at 2.7, with the intent of removing support entirely eventually (though not for a while).

It's not really a like comparison to compare the two.

From what I've seen, the difference between Perl 5 and 6 is much greater than the difference between Python 2 and 3. For this reason, I have very little hope for Perl 6.

"I like Python, but keeping both 2 and 3 alive for so long has caused problems that make it hard to justify for serious projects."

Sounds like a strawman arguement to me. People in the community are aware of the different versions of Python and know how to deal with it. This "issue" hasn't affected Google, NASA or the millions of developers/users that utilize Python to the extent that they are in crisis mode. You can run multiple versions of Python on the same system, there are utilities that make this manageable.

What other language is "your" boss going to pick that you can't find issues with? Does he actually understand the technical details and history of said language? You can find all sorts of issues with any programming language, all of them are "Hopper complete."

Having Python 3 installed does not mean that you cannot install and use Python 2 if you wish to; if you upgrade to 13.04, your copy of Python 2.7 will remain installed, and for other users it's still in the package repositories (if it's not already installed—I'm not certain). But pushing Python 3 forwards makes sense. It is a better language and is the way forward. Having a major operating system promoting it as the primary distribution will be very helpful in continuing Python 3 adoption. I don't agree with the rest of that paragraph, either.

Then to your second paragraph—I actively enjoy using Unity. And as for the Amazon things, I see the direction they're headed in and approve of it, though the Amazon part alone is of no use to me. Canonical is making good things; sure, in the meantime there have been some things which haven't worked quite so well (e.g. I didn't find Unity usable for the first two releases) but their direction is solid, in my opinion.

I think the way the Python community handled this change is really mature compared to several other communities who've been through such change. They've done great work in making sure one single codebase can support 2.6, 2.7 and 3.2/3, Django does this.

Teams using Python to develop, in the present state, mostly base their decisions to chose py2 or py3 based on the maturity of the libraries (py3 ones) they are gonna use. Ubuntu devs are using good judgment here, they are first moving code they use for the OS from 2 to 3 and switch the default python package version. But py2 should be available to any package which specifies it as a dependency. This should be nearly invisible to a normal user. This also gives the much needed push for Py3 adoption.

Python 2 and 3 are in most practical senses two very closely related, but different, languages. So your scenario is not very different from the two groups of developers suggesting Python and Ruby.

By the way, assuming either language satisfies the external requirements for the project, any half-way competent boss would say "Figure it out. Bring me your decision by the end of the day(/week/whatever). KTHXBYE."

ubuntu isn't deciding anything for you. both are available as packages. and the decision to introduce python 3 wasn't made by them anyway.

for new projects where i control deployment i use python 3 (these days, the support is there - in fact in at least one case i am using a python 3 only lib). for maintenance or projects where the client has existing systems, i use whatever is most appropriate.

i am a professional. i get the job done. what more is there to say? oh, yeah, running round throwing a hissy fit for internet points.

Arch has python2 and python3 with the /usr/bin/python symlinked to python3. Anything that depends on 2 uses, well, 2.

It is the bane of backwards compatibility breakage in language semantics. I sometimes think maybe Python3 should have been another language, but it is understandable when there is so little syntactic breakage between the two you want to try to tie them together than diverge on the unicode issue.

I've worked in environments where classic ASP, .NET 1.0, .NET 3.5 and 4.0 are all in production, some on the same server. I imagine there are similar tales regarding production environments for Java and Ruby etc. If you cannot run different versions simultaneously you have a problem. Thankfully you can.

I hope this is some sort of development/project manager rather than a business manager, otherwise they shouldn't be choosing the language at all!

Get a different boss, that one sucks.