
Extend Python 2.7 life till 2020 - oal
http://hg.python.org/peps/rev/76d43e52d978
======
drewcrawford
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...](http://www.kalzumeus.com/2013/06/17/if-your-business-uses-
rails-2-3-you-need-to-move-to-a-supported-option-asap/)

~~~
muyuu
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.

------
chimeracoder
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/](http://python3wos.appspot.com/)

~~~
a1a
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.

~~~
raverbashing
" why bother learning Python 3?"

Unicode

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

Really, it's worth it.

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

~~~
ubernostrum
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.

~~~
calroc

        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.

~~~
shitgoose
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.

~~~
pekk
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

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

~~~
raverbashing
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

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

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

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

~~~
Goopplesoft
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

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

~~~
jimktrains2
> 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?

~~~
glesica
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.

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

------
Udo
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?

~~~
antocv
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.

~~~
BoppreH
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.

Python2:

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

Python3:

    
    
        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.

~~~
jimmaswell
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.

~~~
BoppreH
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

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

~~~
BoppreH
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.

~~~
jimmaswell
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.

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

------
crusso
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%.

~~~
ama729
> 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.

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

Puppet and chef say hi.

~~~
ama729
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.

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

~~~
skybrian
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.

~~~
kazagistar
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.

~~~
reality_czech
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.

------
makmanalp
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/](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.

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

The list is still too long.

~~~
makmanalp
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.

~~~
kmike84
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.

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

~~~
kmike84
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](https://github.com/scrapy/scrapy/pull/682),
or go to ScrapingHub booth at PyCon and talk to people there.

------
TazeTSchnitzel
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!

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

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

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

------
username223
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."

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

~~~
huxley
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](http://python3wos.appspot.com)

~~~
rguldener
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

~~~
Wilya
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](https://github.com/boto/boto3)

~~~
huxley
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:

[https://github.com/boto/boto/issues/1127](https://github.com/boto/boto/issues/1127)

and also the py3kport branch:

[https://github.com/boto/boto/tree/py3kport/py3kport](https://github.com/boto/boto/tree/py3kport/py3kport)

~~~
jessaustin
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.

------
overgard
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).

~~~
Dewie
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".

~~~
Rubikan
[https://wiki.python.org/moin/Python2orPython3](https://wiki.python.org/moin/Python2orPython3)

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.

------
shadowmint
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'.

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

------
Ellipsis753
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?

~~~
randomsearch
> 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.

~~~
BuckRogers
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.

~~~
tshepang
"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

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

------
danso
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...](http://en.wikipedia.org/wiki/Python_\(programming_language\)#History)

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...](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.

~~~
pekk
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.

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

~~~
pekk
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.

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

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

~~~
pekk
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.

------
lucb1e
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?

~~~
deckiedan
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.

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

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

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

~~~
antocv
Groovy, Guile and Clojure.

~~~
vorg
> 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.

------
ishbits
Anyone know if RHEL 7 will ship with Python 3 in the base, even if not
default? That could go a long way to boosting Python 3 adoption.

I know it's in SCL, but that lacks convenience for a lot of users.

~~~
keypusher
Probably. Fedora has had python3 and the related libs available as packages
for years.

~~~
yeukhon
I am not surprised... Fedora always have the new shiny stuff. You almost never
need to use "PPA" to get the latest from Fedora release to release.

------
estebanrules
Can anyone point me in the right direction of an article that sums up how this
whole fragmentation started? I'm curious to know the history.

------
gaius
By 2020 everyone will have moved onto OCaml anyway.

~~~
estebanrules
Amen. I started to code a bit in OCaml and it's great.

------
Walkman
I just purged Python 3 from my computer. Will not serve much in the next 5
years I guess...

------
estebanrules
I really thought this thread was a prank or joke when I saw the title. Sadly,
it's not. The whole 2.7 / 3.x debacle is a large part of why I I have more or
less stopped coding in Python and moved on to Ruby. The community is a large
part of it as well.

------
gkya
Which kind of means forever?

------
sigzero
That is a huge mistake.

------
crimsonalucard
This is like windows XP.

------
ssweens1
Viva la 2.7!!!

~~~
ssweens1
Thanks for the downvote, douchebag downvoter.

------
stefantalpalaru
I still want to see a Python 2 fork getting the care it deserves. I don't
trust the motivations of its current developers.

~~~
illumen
You're welcome to a refund.

~~~
stefantalpalaru
I don't want a refund. I want core developers that will not waste my time with
backwards incompatible changes, developers that care about performance
regressions and fixing bugs more than being buzzword compliant.

I contribute back to the community and I take the time to make sure my open
source code works with both Python 2 and Python 3, but I will not drink the
kool-aid. Not even for upvotes on HN ;-)

------
mirsimiki
open a shell and type 'import antigravity'

------
SEJeff
Python 2.7.7 aka the Duke Nukem Forever edition!

~~~
SEJeff
Gotta say I'm shocked the HN crowd downvoted this.

~~~
PhantomGremlin
Really? Or are you being sarcastic? For the most part the HN crowd thinks like
Kay from Men in Black: "No, ma'am. We at the FBI do not have a sense of humor
we're aware of."

Slashdot has always highly valued humor. "+5 Funny" is a highly sought after
moderation. So, perhaps in reaction, HN usually downvotes attempts at humor.

Neither approach is "better". It's just how the respective communities have
evolved.

~~~
PhantomGremlin
Ha ha. That's funny. My comment has been downvoted. So even _meta_ discussions
about humor are frowned upon in this establishment.

