9 ms·

Extend Python 2.7 life till 2020

385 points by oal 12y ago

borplk 12y ago
Damn. I hope my grandchildren see the day when Python 3 is commonplace.
- oleganza 12y ago
  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.
  - dtech 12y ago
    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)
    - shadowmint 12y ago
      See, when they invented new web browsers, the old websites still worked on them! ...and therein lies the difference.
      - rm445 12y ago
        Er, not all of them, that's why the old browsers were still used.
      - SEMW 12y ago
        > 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 https://en.wikipedia.org/wiki/Quirks_mode
        shadowmint 12y ago
        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'
    - JoeAltmaier 12y ago
      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?)
  - jabagonuts 12y ago
    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.
    - oleganza 12y ago
      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?
      - maxerickson 12y ago
        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)
  - trentlott 12y ago
    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.)
    - danohuiginn 12y ago
      that's quite an achievement, considering it was only released 4 years ago!
      - muyuu 12y 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.
    - bsg75 12y ago
      > 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.
    - kazagistar 12y ago
      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.
- huxley 12y ago
  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
  - dtech 12y ago
    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.
  - rguldener 12y ago
    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
    - maxerickson 12y ago
      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)
    - Wilya 12y ago
      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 12y ago
        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
undoware 12y ago
...also, he's renamed it "Python XP"
stefantalpalaru 12y ago
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 12y ago
  You're welcome to a refund.
  - stefantalpalaru 12y ago
    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 ;-)
SEJeff 12y ago
Python 2.7.7 aka the Duke Nukem Forever edition!
- ixmatus 12y ago
  While this comment isn't particularly constructive to the discussion (nor is the one I'm writing right now), I did have a laugh :)
- SEJeff 12y ago
  Gotta say I'm shocked the HN crowd downvoted this.
  - PhantomGremlin 12y ago
    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 12y ago
      Ha ha. That's funny. My comment has been downvoted. So even meta discussions about humor are frowned upon in this establishment.
- pekk 12y ago
  Reddit-like meme humor belongs on Reddit.
chimeracoder 12y ago
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/
- jlebrech 12y ago
  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.
  - numbsafari 12y ago
    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: https://python3wos.appspot.com https://python3wos.appspot.com
- a1a 12y ago
  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.
TazeTSchnitzel 12y ago
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!
- jordigh 12y ago
  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 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".
  - antocv 12y ago
    Captain hindsight then to the rescue, py3 shouldnt have existed and a 2.8 should habe been made.
- jiggy2011 12y ago
  PHP5 was almost completely backwards compatible with PHP4, Python 3 has much larger changes.
  - Macha 12y ago
    Just the entire OOP system changed. However, nobody noticed because nobody used the OO features in PHP4.
    - jiggy2011 12y ago
      IIRC PHP5 mostly added features to the OOP system so old code would still work even if it was suboptimal.
    - nolok 12y ago
shadowmint 12y ago
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'.
dehrmann 12y ago
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.
PythonicAlpha 12y ago
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 12y ago
  > 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 12y ago
    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 12y ago
      Right. And they even changed it, I think in Py3.3 -- but that was very late, when many people already decided not to port.
  - deleted 12y ago
    [deleted]
andhess 12y ago
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.
- illumen 12y ago
  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.
- pekk 12y ago
  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.
makmanalp 12y ago
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.
- kmike84 12y ago
  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.
- bitL 12y ago
  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.
- lucian1900 12y ago
  Also fabric, supervisor, graphite, gevent, eventlet, Twisted, etc. The list is still too long.
  - makmanalp 12y ago
    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.
    - 12y ago
crusso 12y ago
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%.
- Igglyboo 12y ago
  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(?). http://python3wos.appspot.com/ http://python3wos.appspot.com/
  - Luyt 12y ago
    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/ http://legacy.python.org/dev/peps/pep-3156/).
  - tshepang 12y ago
    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.
- Genmutant 12y ago
  Where do you get that many libraries that aren't converted? Most, at least the ones still under development, are.
  - RogerL 12y ago
    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.
deleted 12y ago
[deleted]
lucb1e 12y ago
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 12y ago
  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 12y ago
    Python 2.7 was released after 3.1 and contains many features backported from the 3.x series in order to ease migration.
    - deckiedan 12y ago
      Ah, yeah. Sorry, my history is a little hazy. I claim I was going for the spirit of the situation, rather than the details... ;-)
- grayclhn 12y ago
  I think that this move is intended to prevent a fork like that.
  - deleted 12y ago
    [deleted]
- claystu 12y ago
  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.
- 12y ago
ishbits 12y ago
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.
- jkbr 12y ago
  RHEL 7 will ship with Python 2.7.5. There is no mention of Python 3 in the release notes. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/7.0_Release_Notes/index.html#bh-python-2.7.5 https://access.redhat.com/site/documentation/en-US/Red_Hat_E...
- keypusher 12y ago
  Probably. Fedora has had python3 and the related libs available as packages for years.
  - yeukhon 12y ago
    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.
mirsimiki 12y ago
open a shell and type 'import antigravity'
danso 12y ago
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)#History 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/ 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 12y ago
  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.
yason 12y ago
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.
- maxerickson 12y ago
  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.
  - ma2rten 12y ago
    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.
    - dragonwriter 12y ago
reality_czech 12y ago
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 12y ago
  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.
  - reality_czech 12y ago
    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.
Walkman 12y ago
I just purged Python 3 from my computer. Will not serve much in the next 5 years I guess...
wirrbel 12y ago
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.
ssweens1 12y ago
Viva la 2.7!!!
- ssweens1 12y ago
  Thanks for the downvote, douchebag downvoter.
crimsonalucard 12y ago
This is like windows XP.
Udo 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
      - heinrich5991 12y ago
        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.
eliben 12y ago
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 12y ago
  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
- Rubikan 12y ago
  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.
andr 12y ago
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 12y ago
  Groovy, Guile and Clojure.
  - jessaustin 12y ago
    Guile? Really?
  - vorg 12y ago
    > 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.
- abenga 12y ago
  Python 3, say?
  - rspeer 12y ago
    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.
- 12y ago
gaius 12y ago
By 2020 everyone will have moved onto OCaml anyway.
- estebanrules 12y ago
  Amen. I started to code a bit in OCaml and it's great.
sigzero 12y ago
That is a huge mistake.
overgard 12y ago
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).
- sp332 12y ago
  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.
- Dewie 12y ago
  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 12y ago
    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.
drewcrawford 12y ago
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-rails-2-3-you-need-to-move-to-a-supported-option-asap/ http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...
- ubernostrum 12y ago
  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.
gkya 12y ago
Which kind of means forever?
estebanrules 12y ago
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.
bmoresbest55 12y ago
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 12y ago
  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.
estebanrules 12y ago
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.
Ellipsis753 12y ago
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 12y ago
  > 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 12y ago
    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.
username223 12y ago
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."
piokuc 12y ago
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.

385 points by oal 12y ago

borplk 12y ago

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

oleganza 12y ago
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.
- dtech 12y ago
  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)
  - shadowmint 12y ago
    See, when they invented new web browsers, the old websites still worked on them! ...and therein lies the difference.
    - rm445 12y ago
      Er, not all of them, that's why the old browsers were still used.
    - SEMW 12y ago
      > 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 https://en.wikipedia.org/wiki/Quirks_mode
      - shadowmint 12y ago
        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'
  - JoeAltmaier 12y ago
    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?)
- jabagonuts 12y ago
  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.
  - oleganza 12y ago
    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?
    - maxerickson 12y ago
      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)
- trentlott 12y ago
  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.)
  - danohuiginn 12y ago
    that's quite an achievement, considering it was only released 4 years ago!
    - muyuu 12y 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.
  - bsg75 12y ago
    > 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.
  - kazagistar 12y ago
    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.
huxley 12y ago
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
- dtech 12y ago
  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.
- rguldener 12y ago
  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
  - maxerickson 12y ago
    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)
  - Wilya 12y ago
    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 12y ago
      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

undoware 12y ago

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

stefantalpalaru 12y ago

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 12y ago
You're welcome to a refund.
- stefantalpalaru 12y ago
  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 ;-)

SEJeff 12y ago

Python 2.7.7 aka the Duke Nukem Forever edition!

ixmatus 12y ago
While this comment isn't particularly constructive to the discussion (nor is the one I'm writing right now), I did have a laugh :)
SEJeff 12y ago
Gotta say I'm shocked the HN crowd downvoted this.
- PhantomGremlin 12y ago
  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 12y ago
    Ha ha. That's funny. My comment has been downvoted. So even meta discussions about humor are frowned upon in this establishment.
pekk 12y ago
Reddit-like meme humor belongs on Reddit.

chimeracoder 12y ago

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/

jlebrech 12y ago
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.
- numbsafari 12y ago
  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: https://python3wos.appspot.com https://python3wos.appspot.com
a1a 12y ago
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.

TazeTSchnitzel 12y ago

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!

jordigh 12y ago
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 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".
- antocv 12y ago
  Captain hindsight then to the rescue, py3 shouldnt have existed and a 2.8 should habe been made.
jiggy2011 12y ago
PHP5 was almost completely backwards compatible with PHP4, Python 3 has much larger changes.
- Macha 12y ago
  Just the entire OOP system changed. However, nobody noticed because nobody used the OO features in PHP4.
  - jiggy2011 12y ago
    IIRC PHP5 mostly added features to the OOP system so old code would still work even if it was suboptimal.
  - nolok 12y ago

shadowmint 12y ago

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

dehrmann 12y ago

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.

PythonicAlpha 12y ago

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 12y ago
> 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 12y ago
  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 12y ago
    Right. And they even changed it, I think in Py3.3 -- but that was very late, when many people already decided not to port.
- deleted 12y ago
  [deleted]

andhess 12y ago

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.

illumen 12y ago
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.
pekk 12y ago
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.

makmanalp 12y ago

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.

kmike84 12y ago
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.
bitL 12y ago
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.
lucian1900 12y ago
Also fabric, supervisor, graphite, gevent, eventlet, Twisted, etc. The list is still too long.
- makmanalp 12y ago
  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.
  - 12y ago

crusso 12y ago

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

Igglyboo 12y ago
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(?). http://python3wos.appspot.com/ http://python3wos.appspot.com/
- Luyt 12y ago
  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/ http://legacy.python.org/dev/peps/pep-3156/).
- tshepang 12y ago
  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.
Genmutant 12y ago
Where do you get that many libraries that aren't converted? Most, at least the ones still under development, are.
- RogerL 12y ago
  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.

deleted 12y ago

[deleted]

lucb1e 12y ago

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 12y ago
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 12y ago
  Python 2.7 was released after 3.1 and contains many features backported from the 3.x series in order to ease migration.
  - deckiedan 12y ago
    Ah, yeah. Sorry, my history is a little hazy. I claim I was going for the spirit of the situation, rather than the details... ;-)
grayclhn 12y ago
I think that this move is intended to prevent a fork like that.
- deleted 12y ago
  [deleted]
claystu 12y ago
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.
12y ago

ishbits 12y ago

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.

jkbr 12y ago
RHEL 7 will ship with Python 2.7.5. There is no mention of Python 3 in the release notes. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/7.0_Release_Notes/index.html#bh-python-2.7.5 https://access.redhat.com/site/documentation/en-US/Red_Hat_E...
keypusher 12y ago
Probably. Fedora has had python3 and the related libs available as packages for years.
- yeukhon 12y ago
  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.

mirsimiki 12y ago

open a shell and type 'import antigravity'

danso 12y ago

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)#History 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/ 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 12y ago
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.

yason 12y ago

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.

maxerickson 12y ago
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.
- ma2rten 12y ago
  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.
  - dragonwriter 12y ago

reality_czech 12y ago

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 12y ago
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.
- reality_czech 12y ago
  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.

Walkman 12y ago

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

wirrbel 12y ago

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.

ssweens1 12y ago

Viva la 2.7!!!

ssweens1 12y ago
Thanks for the downvote, douchebag downvoter.

crimsonalucard 12y ago

This is like windows XP.

Udo 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.
    - heinrich5991 12y ago
      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.

eliben 12y ago

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 12y ago
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
Rubikan 12y ago
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.

andr 12y ago

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 12y ago
Groovy, Guile and Clojure.
- jessaustin 12y ago
  Guile? Really?
- vorg 12y ago
  > 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.
abenga 12y ago
Python 3, say?
- rspeer 12y ago
  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.
12y ago

gaius 12y ago

By 2020 everyone will have moved onto OCaml anyway.

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

sigzero 12y ago

That is a huge mistake.

overgard 12y ago

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

sp332 12y ago
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.
Dewie 12y ago
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 12y ago
  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.

drewcrawford 12y ago

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-rails-2-3-you-need-to-move-to-a-supported-option-asap/ http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...

ubernostrum 12y ago
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.

gkya 12y ago

Which kind of means forever?

estebanrules 12y ago

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.

bmoresbest55 12y ago

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 12y ago
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.

estebanrules 12y ago

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.

Ellipsis753 12y ago

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 12y ago
> 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 12y ago
  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.

username223 12y ago

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

piokuc 12y ago

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.