[prodigal_erik]

Relying on a service hosted by a third party is fundamentally different. Nobody, not even Torvalds or van Rossum, could throw a switch and shut down your Linux boxes or your Python interpreter, so any needed migration to an incompatible system can happen at your convenience.

[borism]

have you tried migrating to Python 3.0 yet?

[georgemcbay]

Irrelevant to the grandparent's point because your Python 2.x interpreter isn't going to stop working at the whim of an outside party.

[saurik]

This argument come up often, but makes no sense as it ignores the fact that software rots. I cannot keep running Python 2.x indefinitely without maintenance because knowledge of its flaws will slowly escalate until it is a security risk to keep operating it. If this doesn't happen to the tool itself, then it will happen to one of its critical dependencies, like an old version of SQLite it requires, or the previous generation of OpenSSL.

Projects like Python, that simply don't care about maintenance costs of things that rely on it are simply being naive: they are pretty much saying "yes, you invested a ton of time into building code for Python 2; but those days are over: we, at some random shifting date in the future, are going to drop support for this, so if you want to get security updates to it, or hell: even upgrade to a newer version of Ubuntu with minimal pain, you now need to drop everything you are doing and reread all of that code to update it for our seemingly arbitrary changes, retesting the whole thing in the hope of finding any regressions you introduce; that, or go off-grid, maintaining this code and related infrastructure yourself". Seriously?

Imagine if Linux 2.6.100 decided to drop support for socket(), because it is (truly) a painful API to support multiple transport layers with; /even if/ they said "dude, you can still just type socket_old, and we have a crazy preprocessor that hopefuly, if your code is obvious enough, does this search and replace for you", would you still be able to take their dedication to being a platform seriously?

[glenjamin]

There's a big difference between flicking a switch to turn off python 2, and slowly deprecating it over a period of years to a new (better) system with well doucmented differences and a clear migration path.

Python 3 started in 2006 (http://www.python.org/dev/peps/pep-3000/), if you've managed to stave off software rot for the last 5 years, I'm sure you can take the extra step to support python 3.

[saurik]

Upgrading to Python 3 is simply not an option for me at this time as I am depending on libraries that still require me to be using Python 2: Python 2->3 is an "all or nothing" endeavor due to the horrendously incompatible way they have handled this transition. I mean: the fact that five years /have/ passed and Python 3 is still a silly pipe dream for almost all users of Python should tell you something about how poorly this was done.

Now, of course, to the extent to which I can, I've used Python 2.7's "from __future__ import" mechanism to pull as many features as I can from Python 3 to help transition, but even that has been stupidly painful: importing Python 3's gratuitously different division operator (which you can't automatically process and convert as you need to know whether the denominator is a float or an integer) was very very VERY painful on all of my careful image processing code (suddenly getting, or not getting, half pixel offsets and widths in various places).

Meanwhile, I don't see any benefit at all to me making these changes... requiring "as" instead of a comma for exceptions?... /removing/ the 2.7 ability to mark a string constant with a b-prefix, forcing an ambiguity between 2.6 str and 3.0 bytes? Are you seriously telling me that these were so important as to cause there to be a five year rift in the language community?

In all seriousness, a better usage of my time (rather than messing around porting my 2.x code to 3.x code) would have been to make a patch to Python 3.x to let you "from __future__ import hindsight" to let you use Python 2.x syntax with the Python 3.x interpreter, at which point 99% of these incompatibilities would be irrelevant. Of course, hindsight /is/ 20/20: I can't go back in time and reinvest that time better; but, I certainly have learned my lesson about using Python.

[rbonvall]

> the fact that five years /have/ passed and Python 3 is still a silly pipe dream for almost all users of Python should tell you something about how poorly this was done.

So far, it has been just how it was meant to be. It was never the goal for Python 3 to be the default Python version by year 2011.

[burgerbrain]

You are free to hire developers to maintain whichever version of Python you like for you.

Plenty of companies do exactly this with Linux.

[saurik]

If you feel your company has the resources to take over maintenance of something like this, with the understanding that you will no longer be benefiting from the open source contributions from the community (as Python 3's VM has diverged quite rapidly, destroying a ton of projects like mod_python and Unladen Swallow), all I can say is: more power to you. However, continuing to build your empire on land we now all know to be quicksand, just so one day you have the fun job of maintaining the water table to keep your expensive buildings from sinking, seems like poor judgement.

[gnaffle]

I'm sorry, but this sounds like whining to me.

In this case, you're not the only one building an empire on the quicksand (which by the way, was freely provided by voulenteers, which only make changes to the quicksand in an effort to _improve_ it).

The effort to keep the platform working to support your old castle will usually be shared with others, just like with the Debian project which keeps old software versions updated with backported security fixes for many, many years just so that you can sleep well each night.