Hacker News new | past | comments | ask | show | jobs | submit login
Extend Python 2.7 life till 2020 (python.org)
385 points by oal on April 13, 2014 | hide | past | favorite | 278 comments

There are a lot of comments here from people who aren't on the python-dev list and don't really understand what this diff actually means.

The core developers are not required to maintain 2.7 post-2015, and most of them won't be involved in it. That part hasn't changed.

What is happening is that Red Hat is preparing to cut a RHEL 7 release, which AFAIK depending on how much you pay them they support for 13 years. So they will need to figure out how to support 2.7 themselves at least through 2027.

Here is where I am reading between the lines. RH are well within their right to fork Python and keep their maintenance patches to themselves and their customers (Python's not copyleft). But, they are nice guys and so maybe they are willing to upstream their changes at least for awhile if there is still a Python project willing to accept them. Again, this is my speculation based on the ML discussion, not what RH has actually said they will do.

An analogy can be made to Rails LTS, a commercial fork of Rails 2.x that patio11 was involved in [0]. Inevitably somebody is going to step in to support 2.7, and so let's see what we can do to avoid a situation where the only way to keep running 2.7 is to subscribe to RHEL.

Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download.

So really what is happening here is not very exciting. The core committers aren't doing anything different than leaving the project as originally planned. What is happening is that they will leave the lights on in the source control repository and on the FTP server, so as to capture the free labor from people at large companies who have an interest in continuing to support 2.7.

The alternative is that RH and other vendors create proprietary and expensive forks of Python 2.7. That may end up happening anyway, but it will take longer for your employer to notice you should stop contributing your patches back if binaries still appear on python.org and you don't have to ask IT to set up SCM and a bug tracker, etc.

[0] http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...

There's a parallel in the Python world too: when Django 0.95 made a ton of backwards-incompatible changes, there were a lot of existing installs that simply couldn't make the jump quickly. So bugfix-only support continued, as a community project (I should know, since I helped with it), for quite some time past the official EOL.

It would be a massive strategic mistake to reject 2.x maintenance releases, or any kind of releases, on python.org as soon as 2015.

I'm a few thousand emails back on python-dev, but:

> Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download.

Note that 2.6 had no installers released beyond 2.6.6 (2.6.9 was the eventual last release), so there's a precedent for source-only releases if nobody does want to provide Windows/OS X installers.

> which AFAIK depending on how much you pay them they support for 13 years

10 years actually. This is a common misconception from those who do not read the lifecycle page carefully.

It's 13 years with the Extended Life Phase and the Extended Life Cycle Support subscription which provide security fixes https://access.redhat.com/site/support/policy/updates/errata...

Except ELS applies only to RHEL3/4 (which gets only 7 years of support otherwise) and also covers a limited amount of packages.

This is really disappointing to see - I fear that it will slow adoption of Python 3 even further, when it was just reaching a tipping point[0].

When I first learned Python, I learned Python 3 first because it was newer, and I figured everyone would be using it soon enough. Little did I know that Python 2 would continue to be supported for over ten years after that!

Some people make a big deal about figuring out "which" Python to learn - that's not really much of an issue, because Python 3 isn't so different from Python 2 that it's hard to pick up the other very quickly (especially given how much has been backported to 2.7). But it's unfortunate to see people continuing to write new code in Python 2.

[0] http://python3wos.appspot.com/

On the other hand, if you are comfortable with Python 2, it will do the job, and you know it will be supported for a foreseeable future, why bother learning Python 3?

I assume there is a good answer for switching to Python 3, but I honestly don't know (haven't bothered to do any research though).

Harshly put: I care about getting my python script working as soon as possible and for a foreseeable future - I couldn't care less for the Python language and it's future.

> On the other hand, if you are comfortable with Python 2, it will do the job, and you know it will be supported for a foreseeable future, why bother learning Python 3?

This bothers/worries me, because I don't understand where this notion that "learning Python 3" requires significant effort or commitment comes from. Python 3 isn't massively different from Python 2. I learn more "new stuff" (APIs I've never used before, implementation details of systems I work on/with, etc.) basically every month than that difference.

Python 2 -> 3 can be a big step because of dependencies. The difference between the languages themselves is negligible (and yet, IMHO for the better). You don't need to learn any new ways of thinking here.

If you're comfortable with Python 2, you're comfortable with Python 3 as well. If your dep ducks are in a row and you're writing new code, it's an obvious choice.

It's not about the language. Languages are easy to learn. I can learn one between breakfast and lunch and be productive by dinnertime.

I use Python 2 because of the massive ecosystem of libraries that have been written, work, and will continue to work.

It's shortsighted and more than a little irresponsible to shame or muscle people into switching. Code that works is valuable. Code that has been tested for a decade is valuable. What's not valuable is forcing an upgrade to a platform that nobody wants to upgrade to while forcing us to abandon third-party code with years of field testing that the authors aren't ever going to port to python 3.

^ This is the best comment in the entire thread.

Nobody who's making anything that actually matters and delivers value to customers cares about the improvements in the language itself as much as they care about the battle-tested libraries that come with that particular language.

If you are a company that actually matters (has significant growth / users) and you use Python3 over Python2 as the main language in your stack, I'd like to know who you are, if you even exist.

I'm a build engineer at Intel (100,000+ employees), and we strictly use Python3. You act like it's a completely different language. It hurts the community when you blow the situation out of proportion. There are innumerable Python3 libraries, and while there are most certainly more in the Python2 camp, who cares? This isn't a dick-measuring contest; it's a change for the better in a language we all seem to like.

Is Python the main language you guys use, over Java/C++ as well? And what's the context of its usage? How do you deal with stuff that's missing, do you just have your own employees fork and port existing libraries?

I'm not asking as a challenge to you, I'm genuinely curious.

> It's not about the language.

It was for the OP. Can't fault me for my reply not reading on an argument you make after the fact :).

> I use Python 2 because of the massive ecosystem of libraries that have been written, work, and will continue to work.

I too like useful libraries that save me time and effort, and I agree that Python 2 is extremely strong there. I feel like Python 3 is catching up and has a pretty good library story going for it already (my gratitude to those who make that happen through their contributions), in addition to being a language I find more enjoyable and productive to use than Python 2.

> It's shortsighted and more than a little irresponsible to shame or muscle people into switching.

I don't think I've done either, and I think you're being quite rude here. I was merely voicing my opinion that the magnitude of the differences between Python 2 and 3 gets blown out of proportion. Please be mindful of the context.

> that nobody wants to upgrade to

Not so, I've wanted to and have upgraded things to Python 3, and so have others.

As for the whole "forcing" stuff - well, yes, it happens. As a user of a language you're part of a community, and communities can sometimes decide to go into a direction you don't agree with. It's frustrating and difficult, and you can reasonably decide that it's a deal-breaker and leave the community. Often however it's valuable to instead put one's efforts into achieving consensus, and then defending and carrying that consensus, even if it's not what you originally wanted - shit tends to get done faster then, to the benefit of all.

I didn't mean to be rude. I'm sorry if it sounded that way. I think it's both shortsighted and irresponsible to force people to abandon libraries that work.

The parent poster wasn't concerned about learning the language. They were concerned about dependencies that work, which is what I was saying:

"I care about getting my python script working as soon as possible and for a foreseeable future - I couldn't care less for the Python language and it's future."

Yes, I didn't mean "nobody" literally. I should have said "few."

> The parent poster wasn't concerned about learning the language. They were concerned about dependencies that work

No, read more of the thread - to quote the OP:

> I rarely write anything high language besides small scripts.

OK, so you could argue that their scripts probably remain small because they call into tons of third-party code, but honestly I get the impression that it's a case of working with the included batteries and not being overly concerned with dependencies. If it was solely about deps availability, they probably wouldn't have talked about "learning Python 3" as their sticking point.

Well, the one big reason was that you were going to lose support for Python 2. Guido just took that reason away and now tens of thousands of new Python apps are going to be written in Python 2 because they've got another 6 years to worry about it.

Guido just created a bigger problem. No good deed goes unpunished.

> Well, the one big reason was that you were going to lose support for Python 2. Guido just took that reason away and now tens of thousands of new Python apps are going to be written in Python 2 because they've got another 6 years to worry about it.

This shows a serious disconnect from reality. Discontinued support for Python 2 was never a major reason to move to python 3 for apps. Library support is WAY more important in the choice to switch. If all of the libraries worked with Python 3, there would be no reason for app writers not to switch.

Yeah but I understand GP's sentiment. As someone who writes python for my living currently, I'm a little disappointed at this because it's hard to imagine that it doesn't move further into the future the day on which we will switch our code base. I don't need to be a 3-second attention span novelty junkie to just get some pleasure out of using the latest version of the language at my workplace.

It feels like the problem is the black-and-white thinking on the part of developers of every language being either "okay to develop in" or "completely unsupported."

If only there was a way to deprecate a language, with the same meaning as deprecating an API method: "it's not gone yet, but it will be soon, so in strict mode using it is an error." (The main problem to solve would be: strict mode of what? The package manager?)

"If only there was a way to deprecate a language, with the same meaning as deprecating an API method"

One way that usually works is to release a newer version and stop updating the old one after five years. Oh wait...

It's the "using it in strict mode is an error" part that's important. Compilers can automatically refuse to compile deprecated-but-not-broken code. What can automatically refuse to let you start a new project in a deprecated-but-not-broken language?

Where exactly do you get this "tens of thousands" number from?

From the number of Python programmers out there and the percentage using Python 2.

In fact there'd be "tens of thousands" websites made with Python alone (Django et al), so the number of apps in total will be much higher.

Heck, people doing scientific Python are more than 10.000, and they write more than one new apps for their research every year.

Oh, I see. Some people here misinterpreted what I wrote to suggest that Python isn't widely used. Clearly that's not what I meant.

I just dislike how melling basically pulled a number out of his ass, and then used it as "evidence" to back up his claims. I wouldn't even consider it a low-quality estimate, since he doesn't even try to justify or explain how that number was obtained.

In this case, "tens of thousands" could very well really be "hundreds of thousands". It could be significantly less, too. Regardless, it's purely speculative. Using such made up numbers makes his argument weaker than perhaps not using any such value at all.

No, I picked what I thought would be a lower bound. Do you think it will only be a few hundred or few thousand over 6 years? Python is an extremely popular language.

I really do not know. I prefer not to make specific guesses, even lower-bound estimates, when there is insufficient information available.

I've worked in industry for 20 years. People take the same version of the interpreter, or start with existing scripts, to create new scripts. Even if there's a one rev difference, people often don't bother to upgrade. There will probably be hundreds of thousands, if not millions of Python 2.x scripts written over the next 6 years. Many will be small, of course, but it's code that will have to be checked against 3.x at some point. I threw out the conservative number because I thought it would be obvious to most people that given Python's popularity, a lot of new 2.x code will be written.

Obviously, if people were moving more quickly there wouldn't be a need to push out 2.7 support until 2020.

" why bother learning Python 3?"


And of course, you'll move from a platform that's shutting down to one that's evolving

Really, it's worth it.

Python 3 really is a superior language. It took all of the good parts from 2, and left the cruft behind. The downside is that there were so many good parts of 2, and so little cruft, that 3 isn't all that much different. However, it's different enough to break things.

Not to mention `yield from`, which is awesome. Iterators everywhere is a powerful tool.

Unicode works perfectly fine on 2.x.

The 2.x API is incredibly and almost unusably confusing to someone who hasn't already puzzled out the right ways to use it from the many wrong ways that are easier to find.

But that's OK, because 2.7 is exactly for the people who have to maintain old 2.x projects and people who never want Python to change again (and will just move to Rust or something soon anyway, instead of learning and using features in Python 3).

It's hardly shutting down if the support will last another 6 years ...

Well, if you were and are staying on Python 2.7, you are committing to anywhere from 6 (if you start now) to 10 (if you started day of 2.7.0 release) years of a frozen, non-evolving language. No new features, no improvements, nothing -- just the same language, for a decade.

If you can live with that, then by all means stick to 2.7 until your Red Hat support contract expires. If not, consider switching to 3.x.

    No new features, no improvements, nothing -- just the same language, for a decade.
Am I alone in being excited by this? I am figuratively drooling over such stability.

No you are not alone. But you are minority. Majority sees the language not as a tool to solve specific problems, but as a goal, i.e. a way to chase its own tail endlessly. Hence the rudderless pursuit of new. The whole industry is in ADD mode - they moment they create something useful, they discard it and start a new quest.

Projects which never improve get replaced in a few years by new projects which did things better, and by other old projects which improved.

This is not ADD, this is not rudderless. This is preferring actively maintained and improved things over old crap that never gets fixed

Try ANSI C then!

I heard Pascal is all the rage nowadays

Or a good, supported, still used and very stable language: Fortran.

Fortran's most recent standard (Fortran 2008, adopted as an ISO standard in September 2010) was actually adopted more recently than the 2.7 release of Python, so, arguably, Python 2.x has been static for longer than Fortran.

(Obviously, if you said, e.g., Fortran 77, the story would be different.)

Yeah. Actually, sarcasm aside, there's nothing wrong about using those languages at all.

The only pain point is Pascal's lack of a nice-sized community (and thus libraries, support for modern systems etc) nowadays.

Fortran=Math. Wherever there are projects solving math problems, they are running Fortran code. Or at best code ported from Fortran libraries.

If you prefer to work with a platform that will get only bugfixes/security updates go ahead

Potentially no new libraries (for new things and/or API connections)

Not sure how long new versions of existing libraries will keep 2.7 support.

No new libraries? I wonder if 2014's new Python implementation from Guido's employer Dropbox- Pyston, count as significant in your mind?

If you prefer to have no Google App Engine, Azure, Amazon or distro support other than Arch, then have at it. I'll keep that and PyPy, Pyston, Jython, IronPython, PyInstaller, not to mention all programs where Python is integrated like GIMP, all of this is Python2 only.

Enjoy your Python3. I'll stick with Python.

If you're going to build up a large code base, you don't want to have to port it when the libraries you need stop supporting Python 2.

I could have taken that attitude with Django 3 years ago, but they released a new version a week or so after I started using it. That was a simple upgrade, no problems (1.2 - 1.3). I try to stay up to date now, as it keeps many things relevant. Sometimes it causes a bit of hassle.

Now If I had stayed on 1.2, then many of the extra libraries I am using or looking at these days would not be compatible. (Now sometimes I want to use older libraries that have not been kept up to date, but the more popular packages which gain traction - the "more important ones" tend to keep up to date or replaced by ones that do).

A language is different from a framework, but I assume once enough traction is gained, then the same thing will happen with Python - popular packages will end up up on Python 3 only. There seems to be a fair bit of 'push' from the community for people to move to Python 3, with comments of "why not change already".

Python 3 will do the job, what is your argument against it?

That's not a valid reason to avoid making the switch. A big backlog of code that you can't afford to port is valid; it's a business issue. But you? This is a tool of your trade, just do the research.

"Tool of your trade": I have no use of python 3, nor do I have any use for Scala, Perl, or whatever. These could all be considered "tools of my trade".

I rarely write anything high language besides small scripts. Python 2 does the job. If I ever were to need functionality of another language, great, it's fun to learn something new. Our time is limited and we must prioritize. Sadly we cannot invest time to learn everything (well I guess it's possible, but I rather be awesome in four languages than mediocre in twenty).

It will take you an hour at most to read up on all the significant changes in Python 3. Its not like learning Scala or Perl at all. It just cuts some things that have been depreciated for years, makes everything more consistently iterable, adds some nice new comprehensions and literals, modifies certain bits of metaprogramming, and a few other smaller changes. The hardest thing for me was remembering that print is a function in 3, and needs parens.

@a1a I apologize, I was a jerk yesterday. I definitely dropped my forum manners. Not ok!

Just so you do know what the story is with python3: It's mostly a move to proper unicode support (which couldn't be done without breaking backwards compat) but it's a relatively minor change for most code. You'll definitely run into some library support issues, but they should be few and getting fewer. It shouldn't be terrible, and I'd encourage you to do it just for the sake of Guido and the python community, because this transition has been a bit of a burden for them.

> I have no use of python 3

You admit you haven't done any research, so you clearly don't have any basis for making that statement.

Nor have I done research on Perl, Scala, etc. Your missing my point. I am successfully getting my things done in Python 2. I do not have any use for Python 3, Perl, Scala, or any other language. I might have in the future, and hey, some language might be better suited to solve the problem - but as long as it's not drastically better the sensible tradeoff is to stick with Python 2.

That philosophy sounds like one that will cause you to wake up one day and realize your skill set is massively out if date.

Python 3, scala, and pearl all give you new ways of solving a problem. You're missing out on a lot of super cool stuff by not exploring! Outside of maybe library support, I see no reason to not to at least check out python 3.

Fair point. But I'd like to quote my own post above:

>I rarely write anything high language besides small scripts. Python 2 does the job. If I ever were to need

>functionality of another language, great, it's fun to learn something new. Our time is limited and we must

>prioritize. Sadly we cannot invest time to learn everything (well I guess it's possible, but I rather be

>awesome in four languages than mediocre in twenty).

I'll let you in on a secret: Python 3 is Python, just with a couple of improvements. Painting it as an entirely new language like Perl or Scala reminds me of people I used to support who thought their entire computer was different if I gave them a monitor with a different-colored rim. You're making a mountain out of a molehill.

So much for having a big toolbox with lots of different hammers available to you.

I do have a big toolbox, it contains all kinds of screwdrivers etc for low level programming. But I only need one hammer for the few problems I face that is best solved by scripting languages.

To be fair, most of the people I see with sheds with a load of tools in them don't make much and wouldn't know where to begin if they suddenly had to. It's the appearance of the thing that they love.

I chose to learn Ruby in part because of the confusing Python 2/3 issue. I recognize that this is a largely stupid reason to choose a language, but when lots of people suggest that either language is great to pick-up, well, it was another easy reason to lean Ruby over Python.

I don't agree at all that it's stupid (and I'm someone who'd generally pick Python over Ruby). Fragmentation sucks. Really bad fragmentation sucks more. Python's fragmentation is pretty bad.

It's funny reading this from the Zen of Python "There should be one-- and preferably only one --obvious way to do it." [1] while seeing that there are nearly two independent language/ecosystems with the name Python (namely version 2/3).

[1] http://legacy.python.org/dev/peps/pep-0020/

Having a split like that in a language is terrible. You find libraries that work with not-your-version and you envy features that would make your code cleaner/faster/better, but you can't use them.

- "Ugh, that thing is lacking/stupid/messy."

- "Oh, no problem, that wart has been fixed in Python 3"

- "Can we use it?"

- "No."

As a Python developer, usually this isn't a major problem for me when going out and finding libraries. Almost every library you find will support 2.7, so I pretty much stick to 2.7 when using or writing any code. I miss some of Python 3's good features but the library ecosystem is more important to me.

It's a real pain in the ass when I try to publish my own, though. The generally accepted rule is that all libraries must support 2.6 through 3.4, and this can be a major hassle.

But you can use Python 3, it is your business if you decide you don't want to.

Not stupid at all. The same concerns and some bad experiences with 2/3 conflicts and deployment issues drove me to Go after investing quite a bit of time with Python, and I've not regretted it yet.

I'm not sure if it was something I did but I also occasionally found that when pip'ing Python 3 libraries with a lot of dependencies, occasionally some of them would actually be Python 2 libraries and things would break.

Hear, hear.

I think it's a strong signal to industrial users that Python is a stable and mature language whose core developers care about practical usage. Pushing Python 3 for ideological reasons ("it's the right thing to do") would alienate a lot of users who have real work to do and cannot invest weeks to upgrade to a version that does not provide them any benefits.

If the Python core developers care so much about practical usage they should never have released python3 with features that break backwards compatibility.

Your argument is right, but they should have thought about that before fracturing the python community.

Yes; I suppose they will be more careful in the future.

The Java model of using separate lifecycles for the runtime/JVM and the language itself is probably a good role model for the future; it allows introducing new language features without any danger of creating library inconsistencies and allows specifying source and VM versions individually.

Personally I feel more at ease going to Py3 without a knife in my neck due to short EOL

Well honestly, python 2* is a lot more convenient to write in a lot of ways, and the benefits of 3 aren't big enough to make up for it for a lot of people/use cases.

> Well honestly, python 2* is a lot more convenient to write in a lot of ways

In what way is python 2 more convenient to write? Outside of the rapidly shrinking set of cases where the best approach to a key problem is addressed by a Py 2 only library -- or the case of "I want to deploy on Google App Engine" -- I don't really see how Py 2 is "more convenient".

On both OSX and many Linux distros, Py 2 comes pre-installed but Py 3 does not. If I'm going to write simple scripts that I'm going to give out to people, it's nice not having to worry about them needing to fuck around to get the script to run.

> On both OSX and many Linux distros, Py 2 comes pre-installed but Py 3 does not.

Because python 3 was not the most stable at the time of distribution of that operating system. Why would I the developer of said operating system release anything but the most stable versions of the language? This would in turn make my operating system at times less stable.

I totally agree. However, until Py3 is packaged standard it's always going to be easier to run Py2 code. For example, I have a friend who does data analysis on OSX and occasionally she gets data in a format that is ugly. I take a look at it and send her a python script that will massage it into something nice.

She's ok with the occasional "sudo pip install ..." to get a library, but if my instructions started with "ok, first install Xcode and then install homebrew" the answer would probably be "it's ok I'll just do it by hand"

Simple script like that are unlikely to be much different between Python 2 and 3 unless you are using specific libraries. Just make make all the "prints" into "prints()" and "Exeption, e" into "Exception as e", and I can't see what the differences would be.

The difference is in the effort required to make it run at all!

It already is in many distros.

sudo apt-get install python3. Or Whatever the OSX equivalent is.

Its not that difficult.

Arch comes with Python 3 as default.

OSX doesn't come with a package manager.

can't use print x anymore, which also gets rid of "print x,", which printed something without making a newline, for one thing.

> can't use print x anymore

Yes, its a function not a statement, so its now print(x).

> which also gets rid of "print x,", which printed something without making a newline, for one thing.

Sure, you have to do: print(x,end=' ')

if you want to space separate things printed on separate code lines on the same output line.

Of course, if the extra keystrokes bother you, its really not much one-time cost to toss together a library that provides a function that gets rid of them, while keeping the rest of the power of the print function:

    def p(*args, **kwargs): 
        kwargs = {'end': ' '}.update(kwargs)
Though if I was going to bother to do that, I'd probably do it with the same separator for multiple items on the same line as for items on different lines:

    def p(*args, **kwargs): 
        kwargs = {'sep': ' ', 'end': ' '}.update(kwargs)
or, further leveraging print-is-a-function:

    import functools

    p = functools.partial(print, sep=' ',end=' ')

  print(x, end='')
Not quite as nice, but not exactly unusable.


It's a lot less "pythonic".

Dunno. The 3 way is more "Explicit is better than implicit." Though it's a shame Python 3 messes up http://xkcd.com/353/

I have to continue to beat the drum of gradual upgrades, Py3 features should and now will be slipstreamed into 2.N, this is a good thing.


This isn't disappointing, it is refreshing. Python is dead, long live Python.

Isn't this HACKER news, just hack something popular in python 3. all we need it anything written from scratch to be written in python 3.

I realize you are probably getting down voted because of the way that you wrote what you wrote.

But, I have to say, that during the keynote by Guido this morning, this was more-or-less the sentiment that I was left with, but with a #positivepython-twist.

Listening to Guido, I left with the inspiration to try and help this community make that migration.

I hope that, by this time next year, I can have made some contribution to the community that will help people such as the GP be in a position to use "the latest and greatest".

Here's the list, let's make it green:


How I'm not surprised.

Python 3 didn't offer anything that would have been so useful and desirable that people would've jumped on it the moment it was released. In fact, it was actually a bit worse than Python 2 when it was out and those Python 2 users could continue enjoying loads of libraries to go with, and of course they knew how to navigate around Python 2's quirks so why bother. Sadly, this is still what I think of Python 3: "Why bother?".

Python 3 didn't have enough to warrant a 'v3', really: Python 3 could've just been Python 2.7 if it wasn't for the religious backwards compatility in Python, which, ironically seems to matter a lot. The syntactic and semantic differences weren't big enough that Guido couldn't have worked around the most important improvements into 2.x line and dropped less relevant stuff (like removing 'print' statement etc).

Even if Python 2.7 would've needed some changes to existing libraries, the psychological barrier would've been lower. It's about "Fixing my lib to work with Python 2.7 which is top of the line today" versus "Porting my lib to Python 3.0 which will be the official Python in a few years": guess which one sounds more appealing? Note that the amount of work in both cases wasn't that big.

I think mainstream Python will be 2.x till Python 4 is out.

>it was actually a bit worse than Python 2 when it was out

It still has a few things that really suck!

The thing that bothers me the most is the removal of in-argument tuple unpacking. For example, in python 2.x you could write:

dist = lambda (x1,y1),(x2,y2) : math.sqrt((x1-x2)2 + (y1-y2)2)

Whereas in python 3.x you must write

dist = lambda p1,p2 : math.sqrt((p1[0]-p2[0])2 + (p1[1]-p2[1])2)

Which is just awful to read. It gets much worse when you're trying to program in a functional style and you are using triples or quadruples. Imagine using "x[1], x[2], x[3], x[4]" instead of something like "length, width, height, color".

PEP 3113 attempts to rationalize this change, but it's kind of an awful PEP. It claims "no loss of abilities removed", which is clearly false, and the proposed benefits are highly specious. The entire tuple-unpacking system could just be reduced to the insertion of an unpack instruction at the start of the function. That would actually make a lot of sense with Python's policy of "ask forgiveness rather than permission", since trying this with the wrong tuple length would throw a ValueError explaining what went wrong.

I also miss (but it's not really an important language feature like in-argument tuple unpacking) the ability to do encoding directly on strings. For example,




That was much more convenient than having to import some library and use library methods.

Try Python 3.4

I agree with the sentiment, and 3.2 had some rough edges still, 3.3 is better and 3.4 finally gives a virtualenv similar (or even better) to Python 2

Still sucks when youve got modules with c extensions, lile any usable fast module, the virtualenv doesnt virtualize that.

uwsgi (as an example) has C components and builds/installs on a virtualenv

print as a function made it into Python 2.6 (using future imports). It's probably one of the more purely stylistic choices in 3.X. The function style is probably better for pretty much all shipping code (as opposed to someone typing at an interpreter).

The Unicode switchover is where all the pain is, and it isn't particularly clear that there is a good way to do such a thing.

I for one like the 2.x style print function. I see why it would be a bad idea to have a separate syntax for print from a purist point of view.

But least for smallish scripts which print a lot it give you a better overview because the print line look different than other lines. Sometimes prints can almost be like comments.

> I for one like the 2.x style print function.

2.x didn't have a print function, unless you mean the one from 3 available with a from __future__ import.

In case the grandparent doesn't realize, 2.x has a print statement not function.

I meant function as in functionality. This is really pointless nitpicking.

Knowing the difference between functions and statements is not pointless nitpicking. Not in the least.

Normally I would agree with you - but one of the epic changes between 2.x and 3.x python, was the change of print from a statement to a function - so, in this case, it's not so much nitpicking as pointing out one of the major changes between the two streams of python.

Actually it's a procedure because it has a side-effect.

In python, they are called "functions" whether or not they have side effects. (And, actually, in most programming languages I've seen that have different constructs called "function" and "procedure", the difference is that functions have a return value and procedures don't -- usually, both can have side effects.)

Have you ever used a functional programming language?

I think many folks are reading too much into this. "Extended lifetime" is bug-fixes. The final planned release is 2.7.9 in 2015 - beyond that there will be source-only releases for major security problems. No new features, no non-critical bug fixes.

So this isn't really making Python 3 any less appealing. But the Python core developers cannot with a calm heart abandon all the users of 2.x, given the state of adoption today.

Finally, sensible reasoning. The comments in this thread and the unnecessary publicity this is getting is probably the only thing about this that would lead to the conclusion that this is a push back towards 2.7

But if they still get bugfixes there will be even less incentive to switch for them.

And if I look at the whole thing now, "no new features" is not certain. If people are still unwilling to switch he may consider backpedaling and backport some other features to 2.X.

This is a result of some not so optimal design decisions in the past.

I remember, when Py3 first came out, everything was incompatible -- unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped. Unnecessary incompatibilities in the C-extension-module implementation layer. And so on. The list of incompatibilities was just huge.

Later several of them where dropped, like the string literal trouble ... But than the trouble was already done. Many extension modules where not lifted to the new version, since the overhead was to big.

I think, many more projects would have adopted Py3, if more extension modules would support it.

The huge library of extension modules was always the strength of Python. Now we have many projects still running on Py2, because Py3 did ignore this strength.

> unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped

I mean a hard difference between a string and bytes and strings being utf-8 by default seem to be a necessary (and good) reason?

But unicode strings are the default in Python 3, so they could have kept the 'u' syntax and just let it be a no-op. I think that's what was meant.

Right. And they even changed it, I think in Py3.3 -- but that was very late, when many people already decided not to port.

Speaking as a Python outsider, this looks pathological. If backwards compatibility is such a big hindrance in switching from 2 to 3, why not ship a v2 legacy fallback interpreter along with the new stuff? If you wanted to make it fancy, you could even make a 3-to-2 bridge that allows people to run v2 code from v3.

Am I missing something here?

Well, shipping an official v2 interpreter with v3 would also necessitate continuing to support the v2 code, including all its quirks that C extension modules use. So what just happened would be a necessary first step.

Then, without the fancy v2-to-v3 bridge, it wouldn't really be more useful than just having both interpreters installed separately.

The fancy bridge does sound like a cool idea. We can run Python 2 or 3 code from Julia (with limitations on the data passed between them), so why can't we run Python 2 code from Python 3, with the same limitations?

It's basically possible already with some RPC libraries, but the experience could certainly be streamlined.

The biggest issue people have with python3 is unicode support. Unlike python2 python3 puts a clear distinction between characters and bytes. It also is quite strict about it.

The problem with 2.x scripts is that they mix characters with bytes quite often. This is not something that you can easily fix by a program, because from this perspective 2.x programs are broken and need to be fixed.

What you are suggesting is already available, python 2.x and 3.x can be installed and work side by side without any issues. There's even 3-to-2 conversion tool (converting backward is much easier than the other way since python3 is more strict).

The problem really comes down to distribution maintainers, for example we are talking about Guido extending support from 2015 to 2020 for Python 2.7. So before this announcement, Python 2.7 would no longer be supported in 2015, yet we have geniuses at RedHat still shipping it with Python2.6.

And no, there is no incompatibilities between 2.6 -> 2.7 as there's from 2.x to 3.x

Hm that does sound clever. A preparser to determine what language version then invoke that interpreter. And if the 3 is so good people would switch over to usong its features only very soon.

Maybe py3 just doesnt have good enough features compared to 2 for people to make the switch and shouldnr have existed in the first place?

But gradually introducing changes.

Now python is for all intents two languages instead of one.

It's not possible to determine the language. The extensions are the same and much of the syntax hasn't changed, and many of the backwards-incompatible differences are subtle.


    print(1/2 * 1000)    # 0
    print({b'a': 'bytes', u'a': 'text'}[b'a'])  # text
    print(b'A'[0])       # A

    print(1/2 * 1000)   # 500
    print({b'a': 'bytes', u'a': 'text'}[b'a'])  # bytes
    print(b'A'[0])       # 65
And the merits of doing a backwards-incompatible version have been discussed to death elsewhere.

Python3's treatment of integer literals in that case is bad. The first is the behavior that someone used to programming will expect by default, since those are integers. If you want non-integer operations you should have to use a decimal point in the 1 or 2.

I disagree. A strong type system is good, but in this case pragmatism wins the battle. I personally have been bitten innumerous times by bugs where division was rounded down (usually to 0, which is especially destructive).

Most of the numbers I encounter start as integers and most of the calculations I need are floating-point. This language behavior saves me from sprinkling "* 1.0" everywhere on my code, or from introducing extremely subtle bugs.

And the integer division is always there, one character away:

    print(1//2 * 1000)   # 0

I just think it's nuts that we're upcasting ints to floats implicitly. Explicitness over implicitness is one of Python's guidelines.

Python3's '/' operator is different from Python2's '/' operator. This is clear when you try to overload them. Python2's is called '__div__', while Python3's is '__truediv__'.

The Python3's operator '/' (on numbers) is defined to return a float, and it'll convert any integer parameters as required. The same is true for other operators, like 'True + True' being 2.

Because of these definitions, you should consider the operators as explicit conversions. 'total / sum' is less explicit than 'total / float(sum)', but still clear enough.

And about guidelines, there are others that fit this case:

    Simple is better than complex.
    Flat is better than nested.
    Readability counts.
    [...] practicality beats purity.
PS: I think you made an important argument and I'm glad you did it, even though I disagree with it. I fail to see why you are getting downvotes.

I guess I don't mind it that much.

I went to check out the operation and it seems a on two ints returns an int if the power is a nonnegative int, and a float if it's negative nonzero, in both 2.7 and 3. I didn't expect this kind of inconsistency from python, really.

    >>> type(2 ** 1)
    <type 'int'>
    >>> type(2 ** -1)
    <type 'float'>
I guess it does follow the last line of the guidelines there, though. Looking at this power example, the division returning float now is actually an increase in consistency.

I think it's better to think of it as division being an operation that returns the appropriate type for the operation, i.e., a float where necessary. The type of the operands remain unchanged so "upcasting" is not applicable if you ask me.

Looking at that example, the second one looks more correct to me without thinking about it too much.

But if I was writing it I would space the "1/2" into "1 / 2".

The first says half to me (ok, until I pause and realise it is code I am interpreting), while the second is 1 divided by 2.

The good thing is that you can get that behavior if you really intend it, just use the // operator. I'm really in favor of this change.

Even better is that // has been available in Python 2 for ages, so you can get used to using it everywhere. Evidently they were anticipating this change.

A PEP saying "put a python2 shebang at the top to invoke python2 mode" could make this a solved problem.

What about

import2.7 modulefoo

It could work, but can you imagine the extra complexity for the interpreter? It would require extensive type conversions every time an object passes the version barrier, and all the Python3 libraries' classes would have to be backported for compatibility.

And it's not just a matter of sacrificing core dev hours for the greater good, the result would be much slower and full of gotchas.

This is a very creative idea, ingenuously simple, but I don't think it would fly.

Unfortunately there's no way in knowing whether a Python 2 string (str, not unicode) originating from the module should be interpreted as a bytes string or text string. Python 2 doesn't have the clean separation between bytes and strings.

Solutions might include adding some sort of hinting to specify the conversion, or add a Python2-like string class to Python 3, which would pollute its purity.

There's an easy way to do this already:

#! /usr/bin/env python2


#! /usr/bin/env python3

Python allows you easily to run different versions side by side. There's really no good excuses.

Red Hat is major reason why the migration is so tough. They still ship with Python 2.6.

The best way would be to release a python 2.9 which incorporates most of the changes from 2 to 3 but the unicode change.

The Δ between Python 2 and Python 3 was just too wide. Even with breaking changes, with a small Δ people will just migrate eventually. Migrating projects drag each other over the "barrier" just like water in a hose can be sucked over a wall.

The issue definitely was not the print command, but other things such as ``iteritems()``, etc - by themselves not much to keep you from migrating, but there is a pile of these boring changes next to the big one (unicode).

I think Guido overestimated the appeal of the new unicode handling and underestimated how resentful people are to change. I figure that at least 1/4 of programmers are actually very opposed to each and every migration and a new version has to have enough incentives to counterbalance this built-in conservativeness.

I just got back into some Python programming after a 2+ year hiatus from the language.

I'm stunned that this 2.x vs 3.x debate is still happening and that 99% of all libraries in use* haven't been converted to 3.x. I like the language, but ... damn... If it weren't for the scikit/numpy stuff, I'd stick with Ruby. The Ruby community seems much less fragmented and wants to see the language move forward. It helps a lot that the 800 pound gorilla, Rails, keeps up with Ruby releases.

edit: * By that, I mean that the conversion rate for commonly used libraries hasn't hit 99%.

> The Ruby community seems much less fragmented and wants to see the language move forward. It helps a lot that the 800 pound gorilla, Rails, keeps up with Ruby releases.

You kind of answer your question you know, the reason why Python is so fragmented wrt Ruby is precisely because it has a much larger number of uses case: scientific (numpy/scipy/panda), sysadmin, web (django, bottle, ...), games (Ren'Py, ...), etc. Ruby on the other hand is pretty much just Rails[1]. It doesn't make Ruby a bad language, but then it's a lot easier to handle the migration.

[1] Yes, Ruby can also do games and statistics, but AFAIK, it's nowhere near as much used as numpy is to Python.

Thats wrong, Ruby is also used in a lot of devopsy stuff and I've seen quite a few uses of Ruby in other fields. Also, even the web community is rather fragmented now.

Also don't ignore that Ruby has a _huge_ subcommunity in asia that you rarely get any news from, using the language for many other things.

Still, an aggressive push towards the future is part of the Ruby mindset. If your lib doesn't work with Ruby 2.1, it is not considered maintained. That helped _a lot_ during the 1.8->1.9 transition, which was basically Rubys Python 3 moment. The Ruby community managed to cross that bridge.

> Ruby on the other hand is pretty much just Rails[1]

Puppet and chef say hi.

Well there is a HN front page story just now about Puppet moving to Clojure ;).

(And Chef is part Erlang...)

That being said, my point wasn't that there are no software outside of Rails, that would have been quite a claim, but rather than Ruby is much more defined by Rails than Python is defined by Django, which is why migration which alway be much more difficult on this side of the animal kingdom.

This is completely not true, on PyPi there are more libraries supporting 3.x than 2.x. The only major 2.x packages that I can think of that haven't been ported are twisted and gevent(?).


And in Python 3.4+, much of the async functionality of Twisted will also be available in the Python standard lib itself (asyncio, Tulip, http://legacy.python.org/dev/peps/pep-3156/).

You are reading that wrong. Having 3.x support does not imply lacking 2.x support. In fact, I believe all those libraries support both 2.x and 3.x.

"I'm stunned that this 2.x vs 3.x debate is still happening"

The worst thing to me about this transition is what it says about updating existing languages. Python 2 to 3 wasn't that large, really, and look at the resulting screwup, still ongoing. I was on the pro-Python 3.0 side (though I had 0 influence on the decision) and honesty compels me to admit that I never dreamed that it would go down like this. I never would have been pro-3000 if I'd known.

Anyhow, to anyone who has ever read about Go or Clojure or Nimrod or Rust coming out and asked "Why do we need another languge?", the answer is: "Look at Python 3." If you want to tweak anything about an established language, it's almost easier to "just" bring up an entire new language and stack than to fix the old one. And unless our existing languages are Practically Perfect in Every Way... and they're not... we need fixes, which means we need new languages.

The deprecate-warn-remove pattern seems to work well enough for smaller changes.

So maybe it's only when you want to do something as invasive as switching the default string type that things go so sideways, if that is even the right description for Python 3 (which I think you could argue was really about having a better language available in 2015 or 2016 or so, not just being the Python after 2.7).

Where do you get that many libraries that aren't converted? Most, at least the ones still under development, are.

You guys can downvote me all you want for bringing up an uncomfortable truth, but the fact is that from the outside, it looks like there's still a huge schism in the Python community and that it's not at all obvious that users should be jumping into the 3.x tree to get miscellaneous work done.

As far as specifics, one of the first tasks I wanted to perform was to survey some of the NoSQL databases with some test cases that I would build in Python.

Mongo had a good 3.x driver and I worked with it. Great... but then these drivers all put me into a brick wall trying to use 3.x: couchdb, pycassa, happybase, and cql. There were numerous others that I tried along the way, but I don't have notes on all the failures.

Now, rather than trying to be 3.x pure, I don't even bother checking. I'm just using 2.7 for this project.

Personally, I think the larger problem is package management. Most of my python projects use lots external libraries that often conflicting binaries. I find that difficult to manage as it is.

Python is the least special component in the mix and I would be very reluctant to have to upgrade everything just for 3.x.

He is not saying that 99% are not converted, he is saying the conversion rate is not 99%. E.g., the conversion rate could be 90%, or 80%, and his statement would be correct.

Ah. What a very poor way to phrase that, though.

I'm not that familiar with Ruby, but fix any of its version updates fundamentally break backwards compatibility the way Python did with the Unicode string changes in 3.0?

My organisation has a massive internal platform, with hundreds of applications all developed in Python 2.6. We are in the process of upgrading the base platform to 2.7 but I believe we will never be able to upgrade to 3.x. We have hundreds of thousands, perhaps millions of lines of Python code and it's growing all the time. When we started the project version 3 wasn't really a practical option.

> I'm not that familiar with Ruby, but fix any of its version updates fundamentally break backwards compatibility the way Python did with the Unicode string changes in 3.0?

Yes, the Ruby 1.9 release broke backward compatibility and there was quite a time when lots of Ruby stuff was stuck on Ruby 1.8 and you saw much the same stuff as Python 2 to Python 3.

Indeed, one of the big issues was a major change in string handling (to encoding-aware strings), just as with Python.

It resolved more quickly, but I think that's largely due to the fact that Ruby had less diversity of libraries that were critical in one domain or another than Python, and thus less holding it back from changing over. Python has been something of a victim of its own success here.

This is the path that all dynamically typed scripting languages must follow. Over time, change becomes impossible because the lack of typechecking or static analysis tools means that any change might break something in a subtle and hard-to-diagnose way. And so the language grows by accretion. You end up with something like bash or perl, where there are a million ways to do any one thing. Each way was added at a particular phase of the language's life, and it could never be removed after that. And so the language becomes difficult to learn and unattractive to newcomers, so another scripting langauge pops up, and the cycle of life begins again.

Compare this to a language like golang, where you can just run "go fix" on your code to update it to the latest version. And you don't have compatibility hell, because when you distribute your application, it's a standalone binary. Stuff like go is the future. Get off the dynamic language hamster wheel.

It is easier. On the other hand, Java doesn't drop any deprecated API's either, so static types may not help as much as you think. Migration still has to happen before dropping something.

It seems to be that automatically upgrading your code, even with "go fix", is staying on the hamster wheel. Using a stable language like Python 2.7 is getting off the hamster wheel, since the "hipster" programmers (including me, sometimes) have moved on.

So in a way, Python 3 helps you if all you care about is stability, since people will make changes to 3 and you can keep using 2.7.

The risk/reward ratio is a lot different in those two cases. If a Java library drops support for some API (and many do, in major versions), I will know at compile time, and fix it. If the same thing happens in Python, you may not know until days have gone past and your program crashes. The type system is like a set of unit tests that get written automatically and have 100% coverage.

There is also the issue of how code gets installed on the system. The Python model is that you have a bunch of py files sprinkled throughout the filesystem. In this case, you have a "baling out the ocean with a teaspoon" issue when making a major change. There has to be a flag day when everything changes at once. In contrast, with Go, I can have apps compiled with Go 1.0, Go 1.1, and Go 1.2 co-existing happily on the same system. They don't share library files. (Yes, I understand abut things like virtualenv, but that doesn't help distributions that want to ship your software.)

A big part of why Sun (and now Oracle) has been so conservative about backwards compatibility in Java proper (as opposed to the libraries and ecosystem) is because JDK upgrades have a similar "baling out the ocean with a teaspoon" property. It's all or nothing... you generally only have one version of Java installed, and it has to play nice with everything. If they had integrated the runtime into the binary like Go did, this would be much less of an issue.

I would go one step further: in an effort to maintain binary compatibility, Java ended up trying to do "type erasure with generics", which in my mind is a horrible wart. C# went through the same changes, and built two different libraries for collections to accommodate it.

What I am saying is that it wasn't much prettier in those cases, and golang might not have had the same type of issues yet, but it just hasn't been around for all that long.

Well, Go isn't Java. They are two different languages.

The Java designers wanted jars to be runnable by any virtual machine, ever. This meant preserving some pretty old and nasty hacks (like erasure for generics) to allow old jars to work with new virtual machines.

With Go, you would just recompile and that would be it. Go doesn't even support loadable modules yet (although it's coming soon), so they can do whatever they want with compat. It's unlikely they'll make the same mistakes Java did because they are not blinded by the "write once, run anywhere" ideology.

As much as I'm drawn to languages such as Go that are designed for ahead-of-time compilation to self-contained executables, I don't buy your claim that dynamic languages are particularly susceptible to degeneration. As others have pointed out, Java and C++ are both statically typed, and they've both accumulated considerable cruft over the decades. Go is cleaner primarily because it's newer.

C++ was a mess on day 1 due to the decision to build a sorta-kinda higher level language on a C foundation that was never meant to be used that way. The fact that it was designed by a committee and animated by a philsophy of "features, features, features" pretty much explains everything you need to know about what's wrong with it. Does it really count as degeneration when you're born with the defect?

Java hasn't really acquired that much "cruft." The cruft that it does have is mostly relics of really poor design decisions that were made (again) on day 1. For example, the decision to support thread cancellation, which the designers later realized was dumb, has left a bunch of defunct APIs in the Thread class which you're now not supposed to use. I already talked about how the need for jar compatibility (due to the misguided portability religion) led to the generics issues. Java is an ugly language in some ways, but you can't really say that it degenerated: it was that way from the beginning. In fact, now is probably the prettiest it's ever been (not saying much).

The larger problem of 'language drift' seems inevitable- C++ from 15 years ago will have auto_ptr's sprinkled throughout, Common Lisp (compared to Scheme) has had stuff added and added to it, Java has more stuff tacked on as it grows... but it only really causes a problem when you have something like a dynamic language because you're using one interpreter (usually) for the whole project, and so anything breaking backwards compatibility causes huge problems. (Add to that that interpreted languages tend to have more changes in syntax more quickly than compiled languages).

Could dynamic languages avoid this by having (say) a byte-code compiled backwards compatibility module? I would imagine it looking something like this for Lua:

luac -version=5.0 module.lua -o module.o

and then call into whatever functions you need from module.o in the rest of the project, using the new interpreter for whatever doesn't need to use legacy features.

I see many comments talking about how this will slow down the migration process. But I don't think the situation is that bad.

Most of the py3 wall of superpowers is now green (https://python3wos.appspot.com/) with boto, mysql-python, nltk, python-openid being some of the rare few in terms of not having great py3 alternatives. And most of these have ports on the way already.

So one interesting effect of this is that now that there is some critical mass and people are starting new projects in python3, there is now pressure on package maintainers to have py3 ports. So it's users dragging the packages forward now rather than the packages dragging the users backwards.

Just a quick note: NLTK supports Python 3 for more than year in the main github branch; there were several alpha releases that support Python 3, but no "stable" pypi release or a beta. There is no stable release because of unfinished tasks unrelated to Python 3 support.

Also fabric, supervisor, graphite, gevent, eventlet, Twisted, etc.

The list is still too long.

Have no fear, Paramiko supports Python 3 as of 1 month ago:


Fabric won't be far behind after this.

IMHO there are great py3 alternatives for all of those. Which won't help you when porting, but it won't stop new applications from starting in py3 and will move the process further.

Alternatives don't help when some other project depend on a package that is not fully ported. And this is a problem. It is still a bit harder to quickly build something using Python 3.x. Check trending Python repos for this month:

* portia doesn't work in 3.x because of scrapy, twisted and scrapely;

* psdash - developers don't care;

* jasper-client - developers don't care;

* ansible - Paramico was not ported when development started, now it is a big task to port ansible;

* scrapy - depends on twisted;

* heartbleed-masstest - developers don't care;

* planout - developers don't care;

* beets - not sure what's the reason, either some dependencies or developers don't care;

* reddit - no reason to move for 3.x for a large codebase which is not a library;

* salt - docs says it needs Python < 3 (maybe the reason is similar to ansible's);

* pacemaker - developers don't care;

* pyjvm - developers don't care;

* sentry - large codebase which is not a library.

That's not bad (12 trending packages have 3.x support, 13 don't). But clearly something stops some new packages from starting in py3, and many packages that people find interesting don't work in 3.x. I think that the only way to improve this is to help porting "base" packages that ecosystems depend on; just providing alternatives is usually not a good answer.

* psdash developers don't care ? then why is this: https://github.com/Jahaja/psdash/commit/f05c8e0a1011603d5ef4... * Twisted is getting ported. Scrapy too, according to the FAQ. * Beets ? http://beets.radbox.org/blog/py3k.html * PyJVM ? Who cares ? My point being, the whole community is moving forward.

Cool about psdash, the commit didn't exist when I started to write the comment :)

Twisted and Scrapy are getting ported, and the community is moving forward. But this is not happening because of a miracle - people are making it happen. My point was not that Python 3.x is bad (I think it is good), it was that community still needs help, that writing alternative software is not the best way to do it, and that there are still reasons why writing new Python 2.x code is easier.

Praising 3.x won't make users switch if they need some unported package, and bashing 3.x won't make other people's lives easier either. So let's help twisted, scrapy and other modules to become 3.x compatible.

Scrapy reached an important milestone recently - its test runner can now run tests under Python 3.x; test runner was the main reason why porting haven't really started before. If anybody wants to help then ping me kmike84 at gmail.com, or check https://github.com/scrapy/scrapy/pull/682, or go to ScrapingHub booth at PyCon and talk to people there.

The reason is probably because most people are still more confident writing in Python 2 and many users are using Python 2. Though many of the simple programs really don't require advance features which are only available in python 3. In other words, many of the new projects can be Python 2 and 3 compatible without effort.

boto.mws is absolutely essential for e-commerce on Amazon. I can't even think of moving to 3.x because of that. Not to mention other critical components like Excel processing etc. 2->3 is a major problem in Python, can't understand the thinking behind breaking that much compatibility. Compare this to Java.

NLTK's situation isn't as bad as it looks. I use NLTK 3.0a, which does support Python 3, all the time.

I suppose they're not officially releasing it because there may be some unloved corners of the library that don't work yet on Python 3. But everything I've done with it has worked fine.

That's great that you use NLTK3 and Python 3.x and it works fine! There are no known Python 3.x incompatibilities. But if you find something then please report it.

Issues that prevent a release are not related to Python 3: check https://github.com/nltk/nltk/issues?milestone=2&state=open, https://github.com/nltk/nltk/issues?milestone=3&state=open and https://github.com/nltk/nltk/issues?milestone=1&state=open.

Many reds on the list also have py3 support in branches or forks for unmaintained ones like suds.

Oh for god's sake. Kill the damn thing already.

PHP 4 to 5 was a massive leap compared to Python 2 to 3, but they actually made that leap!

Amongst others, the Mercurial devs talked to Guido during Pycon about the huge porting effort towards Python 3 (with little benefit to the hg codebase). Let's not forget that Python itself hosts its code on http://hg.python.org. And during Guido's keynote (which should be online tomorrow) he said his own Dropbox has a huge Python 2.x codebase live on the servers which is difficult to migrate.

He didn't take the decision lightly. These are just two examples, but there's still lots of big Python 2.x uses out there.

If it's any consolation, his keynote started with a big "forbidden" sign over "2.8".

Captain hindsight then to the rescue, py3 shouldnt have existed and a 2.8 should habe been made.

PHP5 was almost completely backwards compatible with PHP4, Python 3 has much larger changes.

Just the entire OOP system changed.

However, nobody noticed because nobody used the OO features in PHP4.

To this day, old PHP 4 objects code still works in the lastest PHP version

The difficulty of upgrade for PHP didn't come from the devs having to redo / revalidate parts of their code for little to no immediate benefit (like in Python's case) but in the shared hosting companies (un)willingness to make the upgrade when the scripts their users wanted (phpbb, wordpress, ...) worked fine with PHP 4.

And that's why these various projects agreed to a common date of "end of support" for PHP 4, sending a message to hosting companies to either upgrade, or not be able to deploy wordpress and co anymore

I know of a small company (won't publicly shame them) that to this day is actively developing a php 4 code base. The reason is that they use a couple of libraries which do not work in php 5 and don't have the time/manpower to port it.

Do you know what libraries can't be ported without a lot of effort? I haven't heard that in a long time.

Automattic isn't a small company.

Automattic is running PHP 5.4 on their servers, I believe: https://github.com/Automattic/prefork

He was trying to take a cheap jab at wordpress

The point from jiggy2011 is rather that the differences from PHP 4 to PHP 5 didn't break much of the existing PHP4 code.

In PHP 4 for example you had an object model where the constructor was a method named alike to your class. In PHP 5 you got the __construct() magic method, but as a fallback, the method named to your class still works as constructor.

The same holds for properties defined with var instead of public/protected/private. For compatibility again, the var keyword is just interpreted as a public property.

As a third example, PHP5 came with an OOP system with support for interfaces, abstract classes and the final keyword. In PHP4, this wasn't available. So, there is no PHP4 code which uses these concepts, making them work in PHP5 as well. Obviously, this doesn't work the same way around.

There are some backwards compatibility issues, but these are minor in contrast to what you probably had written in PHP4 back then [1]

Now, for Py2 vs Py3 this is a completely different story. Py2 code doesn't run automatically on Py3. See this answer [2], as there were so many porting issues developers didn't had the time to overcome the overhead just to port the code. So: no, you can't compare the PHP 4 > 5 change to the Py 2 > 3 change.

[1] http://www.php.net/manual/en/migration5.incompatible.php [2] https://news.ycombinator.com/item?id=7581584

IIRC PHP5 mostly added features to the OOP system so old code would still work even if it was suboptimal.

There was a massive push from the community for PHP5. They had a similar site to the Python3 WOS and large projects such as Wordpress and Drupal announced PHP5 only major updates. I would link it, but the domain has apparently been left expire and replaced with e-cig spam. So here's some link to comments about the announcement: http://www.garfieldtech.com/blog/go-php-5-go , and then a post about its impact and a desire to to the same again for PHP 5.5: https://groups.google.com/forum/#!topic/php-fig/ogp03OHbVJ0

There were a few reasons why they pushed harder with PHP5 however, especially given the tendency of budget web hosts to use old versions of PHP4 with insecure by default configurations (register_globals etc.).

Yes but PHP5 had compelling reasons for upgrading. py3 has a few tweaks and some annoying syntax changes to make things more "pure"

So, counter-intuitively, the bigger leaps are easier to make than the small ones!

Small ones as Py3, doesn't deserve a major version boost. It simply doesn't have that much to offer.

> py3 has a few tweaks and some annoying syntax changes to make things more "pure"

That may have been true of Python 3.0 vs. 2.x, but Python 3 has moved forward quite a bit since 3.0.

I think the point was there was no "OMG we need that, let's upgrade" feature for most people (unicode maybe).


  * Performance
  * Getting rid of the GIL
  * Improve multithreading (somewhat related to above) - multiprocess is still very bad performance-wise
A fair number of the things in 3.x could have been added to the 2.x series...

Good news. They have another 5-6 years to recognize their mistake and cut Python 3 loose from Python, like Perl did with Perl 6. It's interesting how the same underlying mistake manifests itself in different cultures: Perl 6 was "we'll break all your code, but give you gonzo new features that we hope are useful." Python 3 was "we'll break all your code, but soothe some pedants and browbeat you into accepting the result."

Damn. I hope my grandchildren see the day when Python 3 is commonplace.

Guido's or yours opinions are irrelevant. If people have a lot of code for Python 2.7 and have little incentive to migrate to Python 3, then they'll stick with Python 2.7.

I've used 2.* for about 10 years, quite happily.

If I switch to anything, I'll probably switch to Go.

(I originally typed 2.7, which is nonsense.)

that's quite an achievement, considering it was only released 4 years ago!

Well, the 2.x branch has been rather gracefully backwards compatible for many years. Even the jump from 1.x to 2.x was largely "assisted".

Personally, for me switching to 3 is a massive hindrance and probably I'll never do it. For the kind of things I use Python, the changes are extremely significant and it actually seems to me like a step backwards. It may be an improvement in other respects, though. I don't know.

> If I switch to anything, I'll probably switch to Go.

I think this is what is often happening, given that Go is attracting more Perl/Python/Ruby types than its original target audience of C/C++ developers.

Rewriting your code base is easier then fixing it for 3? That really just sounds like you are being overly dramatic, or looking for an excuse to try something new.

It's just prolonging the inevitable. Discontinuing support for python 2.7 may give people the spark they need to finally suck it up and migrate their code. But hey, if it's supported another 5 years, why bother.

If people have real compatibility problem to migrate to Python 3, harsh policies will do nothing about that. If I'm forced to rewrite my app I may as well rewrite it in Ruby, Go, Java, or whatever. Especially, if Python developers will prove to be aggressive about compatibility. Why would I migrate to Python 3, just to be forced to rewrite everything in Python 4 next time?

Well, you can sort of assume that they learned their lesson.

There also isn't really anything as drastic as the bytes/strings/Unicodes left to change.

(But these are better answers to worries about Python3 than they are answers to porting 2.x code bases)

This is the same logic that got us stuck with IE6 and Windows XP for over 13 years (and we'll probably be stuck with it for a few more, altough IE6 has been dying now for a little while and Windows XP is being migrated off from)

See, when they invented new web browsers, the old websites still worked on them!

...and therein lies the difference.

> See, when they invented new web browsers, the old websites still worked on them!

Yeah. But only because they rendered the old websites in various quirks modes[1] that emulated the rendering engines of the old web browsers.

Thankfully, web browser developers did not share the analagous mindset to the people saying 'lets stick with python2-compatible semantics forever', or we'd still be writing sites that had to be backwards-compatible with IE6, instead of having the option to specify a modern doctype and use IE6-incompatible markup (the analogy to using a python3 shebang line and writing python2-incompatible code).

[1] https://en.wikipedia.org/wiki/Quirks_mode

Whatever. You're splitting hairs.

The sites worked. Quirks mode is now being phased out, but it served its purpose. The analogy Im making is obvious:

Python 3 should have run python 2 code and slowly rolled old semantics into depreciation; this whole mess could never have existed.

Its not as simple as 'just port your code and run python3'

Er, not all of them, that's why the old browsers were still used.

Don't understand; Python 2.x support is already there, how much work is it to NOT delete it? Its a whole different issue - IE6 was a burden on servers with progressive web design. This Python situation is the reverse (obverse? inverse?)

Since it's only bug & security fixes for Python 2.7.x from this point on, the momentum to python 3.x will pick up considerably.

Python 3 compatibility far outnumbers incompatible packages now: http://python3wos.appspot.com

The number of compatible packages is irrelevant. All it takes is one critical package to be stuck on 2.7.

It's not like I can just decide to drop the dependency on boto and twisted from all my work code and migrate to something else.

I understand that these are opensource projects and I should be submitting patches to make the migration faster, but from a business point of view, I have absolutely nothing to gain by doing that instead of just sticking with 2.7.

You are correct, but the number of blockers is getting smaller. I sympathize with your situation, boto is a pretty big blocker (PIL was too until I switched to Pillow) and it impacts several of my projects, but thankfully I can work on porting my code to 3.x with six https://pypi.python.org/pypi/six and still deploy on 2.7 until boto gets there.

and Twisted seems to be making good progress:


The disaster that is unicode in Python 2.7.x is enough for me to use Python 3 for anything I do in the future. And as you said there are enough compatible packages now to make this doable so yay for Python 3, and I say that as a former Python 3 skeptic.

A bit off topic, but what exactly makes boto so hard to port to Python 3? Whenever I look at this page I am puzzled by it still not supporting Python 3

There is a port in the works [0], and apparently they decided to go with a rewrite instead of just a port. I'm not sure of the exact reasoning, but that could explain why it takes them time.

[0] https://github.com/boto/boto3

There has certainly not been a lack of work on porting, there was the neo branch as well, there is some interesting (for some values of interesting) discussion about the approaches to 2.x and 3.x compatibility:


and also the py3kport branch:


I don't know all the backstory, but when I pip-installed awscli in a py3.4 virtualenv this week, it pulled in "botocore", among others. Everything seems to work fine, so at least botocore works on version 3. Since awscli is a very complete AWS interface, it may be just a matter of documentation or a very thin API layer before everything one needs in boto works fine on v3.

Paramiko didn't make a 3.x release until recently.

(That doesn't make it hard or anything, but it seems lots of projects that depend on it were waiting)

I thought 2.7 has always been the bugfix branch and no new features would be ported to the 2.x branch after 2.7 was released? Some things were backported from 3.x to 2.x but that was done with 2.6 and 2.7.

> the momentum to python 3.x will pick up considerably.

People won't leave Python 2.7 for Python 3.x, they'll go to other languages. Python has no right to its users.

bullshit. i have several large Django code bases to maintain and all of them could move to py3 if needed if it wasn't for boto. As soon as they are ready porting boto my next projects will all be py3.

Considering Py2.7, Py3 is actually an "other language". Why would all these people throw out their Python expertise?

The lesson here is that it's important to "sell" new versions of anything. You can't just expect people are going to upgrade because it's the new hotness. Older versions of your own software are often your biggest competitor. (See also: Microsoft and Windows 8).

I think that's also a lesson for the people who are unhappy with the changes. People grumble quietly and just decide not to use the new versions, so the devs have no idea how many people like or dislike each change.

I didn't find it simple to google for what the differences are between 2 and 3. As an outsider to the Python community, that would be very important information to me if I wanted to learn the language. The most immediate answers I got was "use 3 because it's the future".


I don't know what you mean by "I didn't find it simple ....". I googled "python 2 und 3 differences", and that was the first result.

To be fair, what was the reasonable alternative?

Cede control of python 2.x to vendors who continue to demand support and bug fixes?

That would be a disaster; it'd be a moment away from new features and a 2.8 'cant believe its not python'.

...also, he's renamed it "Python XP"

I just thought I'd like to know what Hacker News thinks. Will Python 2.x ever die?

I'm still writing lots of code with it and even quite a lot of new code. It's been around for ages and it feels like almost no libraries have been ported to 2.x yet. On a couple of occasions I've started a project with Python 3.x just to drop it or move to Python 2.x as a library I need doesn't seem to exist for Python 3.x and I don't want to port it over myself. I've never had this issue with 2.x (no libraries support 3.x only.)

Most Python 3.x "killer features" have been back-ported to Python 2.x and I honestly feel little reason to upgrade myself now. When support for Python 2.7 is officially dropped we could fork it and continue. I would hope it wouldn't take huge amount of effort for some people to support it? Just fix bugs and security issues and take pull requests? In that way might Python 2.x even outlive Python 3.x or at least remain more popular?

> Will Python 2.x ever die?

My guess would be that Python 2.x will die at the same time that Python dies, i.e. the "transition" to Python 3 will never really happen, and part of the reason that Python will die is the split between 2 and 3.

I don't think it was obvious that Python 3 would "fail" in this sense, but it seems pretty likely now. Sympathy with Guido; this is essentially a cultural problem rather than a technical one, but as a rule backwards-compatibility tends to be a key component of success as a programming language (or library, or even O/S) evolves.

It's not too late -- a compromise could be found, but it would essentially involve abandoning 3 to a large extent. Not very palatable.

I'm sure Python has many years to go though, so I wouldn't worry about writing new code for the moment. Keep an eye on how things develop and think about jumping to another language if no-one sorts out this mess.

They're not going to sort out the mess. GVR is 100% stubborn on having 2 and 3 live alongside each other till everyone moves to 3. He won't be combining them in any way in a Python 4.0 and slowly removing the Python2 stuff.

I personally won't be moving till GAE, Azure, Amazon, PyPy, PyInstaller, and all Linux distros make the jump. Which at this rate appears to be never.

I'm going to do exactly what you're suggesting, and move off of Python entirely at some point. I'm truly amazed that GVR is dancing with death to kill Python over unicode and cruft. I'm hoping Python (2) becomes the community version and 3 remains the experimental branch.

"never" is a very strong word:

* PyPy has a 3.x branch, which is apparently nearly complete

* Major distros, Ubuntu and Fedora, are also moving; Debian is also discussing it

The Python shop I used to work at, and this is a shop with some pretty big fanboys and apologists, wasn't able to upgrade because of library support, and these are people who would like to.

For reference's sake:

Python 2 was released Oct. 2000 and so will have a 20-year lifetime now. http://en.wikipedia.org/wiki/Python_(programming_language)#H...

Ruby 1.8, which was retired last year, had 10 years of life: https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7...

Obviously, version numbers don't mean the same thing...and Ruby 1.8.x to Ruby 1.9.x (or even 2.x) seems less of a jump than 2.x to 3.x.

This seems like an advantage that Ruby's culture has over Python's. If people didn't stall so much, the process wouldn't be so slow and there wouldn't be a reason to stall any more.

I understand that changing to Python 3 can be expensive but really all that any company or person is doing is prolonging the inevitable. If they have a good product/app/etc. that will last it will have to change to Python 3 and sometime in the future, right? Why keep waiting? Why support something that is considered by it's makers to be inferior? I really would like answers to these questions, if someone is willing.

Some people don't see it as inevitable. They never want to change their code again, and they won't. But they don't want their code to be dead or unused. So what is most convenient for these people is for Python to stop changing.

Years ago, when I first heard about Python 3 and plans to improve the language my first thought was "Yes! Multi-line lambdas are coming!", then I started reading more and found out that Guido actually wanted to _remove_ lambdas all together. I still remember the state of shock I was in after reading that, and a sinking feeling.

The lambdas stayed, fortunately, but, unfortunately, I'm still convinced the whole project was a bad idea. The cosmetic changes which make Python 3 incompatible with Python 2.7 are just not worth the trouble of breaking the compatibility. Has anybody ever tried to estimate the man-hours needed to port the myriads of great Python 2.7 libs to Python 3 and weight it against the advantages of subtle language improvements? I don't think so. Plus, the big Python's problems like GIL are still there in Python 3...

If it was up to me I would drop Python 3 and focus the development effort of the community on improving PyPy and porting libraries to it.

Wow I'm very disappointed. I keep making the effort to transition more to 3, but am frustrated to see so many dependencies only work with 2.7, and thus maintain both libraries. I am tired of this limbo.

Back in the python2-only days, if a library failed to work because of bitrot and lack of maintenance, you wouldn't call that limbo. You'd just replace it. And if you failed to find any library to do something, you'd just write it or do without.

Really? Just move to 3 already! :)

I don't think it's entirely fair to call people who don't upgrade lazy or scared. However, it's really not that hard at all these days. Most packages are ported, and there are many success stories who have documented all the hard bits.

This seems weird to me. Won't this cause a fork in Python at some point, where the 2.7 developers continue on 2.8 or rename it entirely, and another fork continues on what is now Python 3?

Python 2.7 hasn't has any improvements since python 3 began, and it won't. All this announcment means is that Python 2.7 will continue to get security/support for another 5 years.

Python 2.7 was released after 3.1 and contains many features backported from the 3.x series in order to ease migration.

Ah, yeah. Sorry, my history is a little hazy. I claim I was going for the spirit of the situation, rather than the details... ;-)

That was my first thought too.

Who knows where 3.x will be in 6 years, but now a huge number of people will continue to develop in the 2.x series with no worries. Six years feels like a long time when you're at the beginning of them. By the end, maybe it will be easier to just tweak the Python 2.x codebase than switch everything to 3.x.

That depends on how the BDFL of the community dictates. Generally, all the people who matter follow their BDFL religiously.

I think that this move is intended to prevent a fork like that.

Since there still won't be a Python 2.8, I read this as the mainstream Python not evolving one bit for the next 6 years. For me, this would be grounds for moving to a different language.

> Since there still won't be a Python 2.8, I read this as the mainstream Python not evolving one bit for the next 6 years.

No, what it is is "legacy Python 2.7 gets 5 more years where bugfixes that we expect certain major users of Python -- notably RedHat, which has 2.x bundled into releases that have long support terms -- to submit may be published to the world as bugfix (2.7.x) releases".

The mainstream of Python development has been 3.x for years, and that line will continue to keep evolving.

Python 3, say?

Yeah, I don't understand the argument some people have, that Python 3 is bad because it's slightly different from Python 2 and a small amount of their code won't work, so that's why they're switching to a programming language where everything is different from Python 2 and none of their code will work.

Groovy, Guile and Clojure.

> not evolving one bit for the next 6 years [...] would be grounds for moving to a different language

I'd never heard of Guile until you mentioned it. I looks like Scheme. If moving to a lisp-like language, Clojure, which you mention, would be a better choice. It's backers claim they'll be there for the long-term, and it has innovative concurrency constructs.

As for Groovy, it appears to be dying. Oracle went to a lot of trouble to create Nashorn, a zippy Javascript bundled with Java 8, and you can bet they'll be promoting it heavily in the "scripting Java" space to dislodge Groovy. Grails is losing adoption bigtime, getting replaced by Node.js, Play!, Django, and even Rails. When Gradle upgrades to version 2, they'll likely bundle some other JVM languages for their API, e.g. Nashorn.

Guile? Really?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact