Live data from Hacker News

Extend Python 2.7 life till 2020

hg.python.org

161–170 of 286 posts

Re: Extend Python 2.7 life till 2020

#161
post #106

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.

Re: Extend Python 2.7 life till 2020

#162
post #97
post #45

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…

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 thousa…

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

Re: Extend Python 2.7 life till 2020

#163
post #102

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.

Re: Extend Python 2.7 life till 2020

#164
post #45

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…

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

Re: Extend Python 2.7 life till 2020

#165
post #115
post #102

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?

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 o…

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.

Re: Extend Python 2.7 life till 2020

#166

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…

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.

Re: Extend Python 2.7 life till 2020

#167
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.

Re: Extend Python 2.7 life till 2020

#168

Earlier quoted context omitted.

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.

Re: Extend Python 2.7 life till 2020

#169
post #164
post #45

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…

"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 wou…

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

Re: Extend Python 2.7 life till 2020

#170
post #24
post #7

Earlier quoted context omitted.

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 d…

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:

http://twistedmatrix.com/trac/milestone/Python-3.x

Post reply on HN