12 ms·

Python 2.8?

73 points by bootload 10y ago

deleted 10y ago
[deleted]
douche 10y ago
The 2.X => 3.X transition really appears to have been bungled here, which is a shame. I really liked Python before I got deeply into the .Net world, but it has become less than enticing with this fragmentation. Meanwhile other languages seem to have taken up the vanguard position, which leaves Python in kind of an awkward position, between the new hotness and the tried-and-true enterprisey ecosystems
- TylerE 10y ago
  I don't think it's "appears to have been" at this point. Python 3 was released in 2008. Python 3 is now older than Python 2 was on the day Python 3 was released.
- copx 10y ago
  >The 2.X => 3.X transition really appears to have been bungled here, which is a shame. Obviously, the question is what went wrong. Personally I think the dev team gave users too much time to switch. The Python devs should have only given users one or two years to upgrade. Making it clear that all support for Python 2 would end after that period. Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile. They made this worse by backporting features from Python 3 to Python 2, something they should have never done. Python 2 should not have gotten any new features after the release of Python 3. Python 3 advocates like to blame the users for not upgrading, but I think that is / was simply the result of the actions of the dev team which made staying with Python 2 too comfortable and moving to Python 3 not attractive enough.
  - otabdeveloper 10y ago
    No, the problem is that Python 3 sucked, and still sucks. Twisting your user's arms even more painfully won't solve the problem, it will just accelerate users switching away to other languages or forks.
    - scrollaway 10y ago
      There's plenty of problems with Python 3 and the transition, none of them are that "Python 3 sucks". You know that, of course, otherwise you'd have provided an actual claim rather than a generic complaint.
    - throwaway91111 10y ago
      How does python 3 suck? It seems quite pleasant to use for me, and I much prefer the clean bytes/str separation.
  - bzz01 10y ago
    > Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile. This is the core issue, but you're putting cart before horse a bit: if there's not much to gain from switching, why would any reasonable person switch? And, most importantly, why is it a problem that needs solving at all?
  - frik 10y ago
    Exactly. For language devs. It's always good to learn from mistakes from the past. PHP 6 failed, then PHP stayed with 5.x and moved directly from v5 to v7 - that worked out fine. The Python 2 to 3 is an important lesson as well. Ruby (afaik 1 to 2), dotNet 1 to 2 and 4 to dotNetCore 1, Swift 1 to 2 to 3, ... are several more cases that were rocky for developers.
    - riffraff 10y ago
      AFAIR the messy release for ruby was 1.8 -> 1.9 (the new VM, changes to encodings, OS-level threading etc) but both that change and 1.9->2.0 worked out _much_ better than python 2->3. As I understand it, Matz considers the upgrade strategy until now quite successful, mostly because at the same time breaking changes occurred people got things they wanted (e.g. faster VM) which encouraged them to upgrade. Hence the "ruby 3 will be 3 times faster than ruby 2" idea, that's the carrot that should contrast people's will to not update.
      - sjellis 10y ago
        I suspect that Ruby also benefited from having a comparatively young community. There are folks that used Ruby before Rails, but the majority of Rubyists only started in 2006 or later, so they are used to the faster replacement rate of modern Open Source and didn't have so many legacy codebases to worry about.
  - dagw 10y ago
    Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile. Not only that, they effectively took away a lot of vital shiny old things like numpy and django. It was something like 3 years between python 3.0 and the first stable releases of numpy and django with python support. That was 3 years where python 3 was effectively useless to a large number of python developers, and you can lose a lot of momentum in 3 years. Had the core python team gotten together with the teams for numpy, scipy, django and a couple of other big name libraries and coordinated the release of python 3 with versions of all those libraries that would work with python 3, then I imagine things might have gone a lot smoother.
- douche 10y ago
  I'm curious why this is so downvoted...
  - greglindahl 10y ago
    Every single HN thread about Python includes a pointless and repetitive discussion of Python 3 being bungled. I didn't downvote you, but I can see why many others might.
- iaml 10y ago
  They really should have EOL'ed 2.x much quicker then what we have now. When you have that much time there is really no incentive to ever switch.
frunzales 10y ago
The amount of trolling in that thread is incredible. I don't understand why an average Joe needs to contradict Guido on trademark matters.
- scrollaway 10y ago
  Because some people are hateful by nature and see Guido as Satan incarnate for "hating Python 2". And no, I'm not exaggerating, you just need to look at the comments: https://github.com/naftaliharris/placeholder/issues/47#issuecomment-266464920 https://github.com/naftaliharris/placeholder/issues/47#issue... I read through that thread the other day and it breaks my heart to know that there are people who think like that. Honestly. On various occasions I've reasoned (and not reasoned) with the most absurd people, there is always some way to understand where the craziest of logic comes from. But here, I'm just sad. And I'm especially sad because I've seen similar comments on HN (even just the other day). So really, this goes out to anyone who works in tech and feels like this either about Python or about any open source project: Treat your FOSS maintainers with some human decency. It's not the first time I say it, and every time I say it there's always some people nodding at this; "oh yes, of course, well who acts like that really?", those same people turning around a week later, flaming Lennart Poettering for whatever software du jour the guy wrote. sighs
  - afterburner 10y ago
    Team Red, Team Blue, Team Three, Team Two (no direct relation to political parties intended)
  - sfilargi 10y ago
    They should name it Monty. A little humor will help with the tension.
    - BerislavLopac 10y ago
      Or "Parrot".
copx 10y ago
The fork should be called "Lython" as in Legacy Python.
daveguy 10y ago
I'm glad Guido considers this a toy. Anyone interested in helping out the github repo is here: https://github.com/naftaliharris/placeholder https://github.com/naftaliharris/placeholder
- didibus 10y ago
  He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any problem here. The maintener agreed to change the name. I don't expect this project to exist for very long unless it breaks free, but if it tries to just bring 3 features back to 2, I'm not sure it'll make sense for very long.
  - unixhero 10y ago
    The problem is some of the massive python modules that cannot be ported from 2.7 to 3 .x
    - viraptor 10y ago
      Which ones specifically? Many massive ones that held out for a long time are either done or in the process of porting. (twisted, openstack, almost all web frameworks, etc.) PS. https://python3wos.appspot.com/ https://python3wos.appspot.com/ now shows only few packages not marked as compatible from the most popular ones. One group (carbon, graphite, supervisor) are not libraries so they don't really affect others. The other is specific moz* libraries - and they're for Mozilla's internal testing, so nobody else should care that much.
      - unixhero 10y ago
        Yes I was thinking about twisted
    - 10y ago
ram_rar 10y ago
I am afraid that, the python community has messed up 2.x => 3.X transition. Until 3.3, there seemed no incentive to port your codebase to Python 3.X. With golang getting a lot of traction and compiler tools like grumpy (python -> Go), I would rather invest time to transition into golang as apposed to transition to 3.X.
- Cyph0n 10y ago
  Transitioning from Python to Go isn't as easy as you make it out to be. Good luck finding solid alternatives to the likes of Numpy, scikit-learn, Pandas, SQLAlchemy, BeautifulSoup, Flask etc. Oh, and not to mention the community surrounding these and other popular Python libraries.
  - deleted 10y ago
    [deleted]
  - tyfon 10y ago
    All of them work in python 3.x too. Well. I'm not sure about flask, it's not one i use personally.
    - notamy 10y ago
      I've been using flask with python 3.6; it seems to be working fine.
    - Cyph0n 10y ago
      I know, but I was addressing the point about migrating to Go.
  - ram_rar 10y ago
    Numpy / scipy and scikit-learn are the only things that are holding me back. Apart from that, I think its just a matter of time golang will have similar libraries in its ecosystem. Afaik, for regular CRUD apps golang can pretty much replace whole of python with better performance (in terms of concurrency).
placebo 10y ago
Back when python 3 was introduced and after learning of breaking backward compatibility my first thought was, "good luck with that"... Wanting to create something better is not surprising. What was surprising (to me at least) is not seeing that people don't like change unless they see a really dramatic benefit to what they already have, and clearly see that the advantages to making that change far outweigh the discomfort of the process. Most people have a really hard time changing from something they know, even if it's less than perfect. Actually, even if it sucks. Ask any marketer, salesman, social worker or psychologist and you will see this is not limited to programming languages, and beyond the psychology, change has an economic price that needs to be justified. So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did. I don't know whether to attribute this more to the quality of the language or the energy that went into promoting migration to it, but its current adoption rate to me is a mark of success when one tries to compare it with other attempts to reeducate a well established market.
- hueving 10y ago
  Yes, the biggest hindrance to python3 is the fact that python2 is a good language. It's very rare to come across a case where you can tell someone, "if you were using python3, this would be so much easier/more performant." Most of the migrations I have seen have been because of a stick rather than a carrot (e.g. this library we depend on is dropping py2 support). It's definitely the case that the move has only been as successful as it has because of the (relatively) unified effort of popular open source library authors to switch common dependencies.
  - sametmax 10y ago
    Well, another issue is that there are carrots, but they are tough to sell. I have been using Python 3 for 2 years now in production, and I would never want to go back to Python 2. Benefits include: - less boilerplate. Automatic super(), no object inheritance, yield from, generalized unpacking, keyword only args, less itertools import, no need for __future__, f-srings, etc. Basically my code is shorter and faster to write. - better error handling. This one is big. It is easier to get a bug free Python 3 program. You get exception nesting handling, finer file exception granularity, more safety nets (e.g: no more arbitrary object comparison), better error messages, absolute import by default, regular division by default, etc. As a trainer, Python 3 is so easier to teach. - unicode is no just about u''. You have the "encoding" parameter everywhere by default. Everything default to "utf8" naturally. You don't need the # coding: monbo jumbo. There is no more "auto-casting" of bytes. English native speakers underestimate the value of this. As a European, it's invaluable to me, and it is to the rest of the world that is not using ASCII as their main alphabet. Those are really, really great benefits. But terrible carrots. They don't sell. People want big shinny stickers with "+30% perf" which will never be of used for most projects. While those benefits, I guaranty, are stuff all project benefits from, and you feel them a lot once you get used to them.
vaibhavsagar 10y ago
This is wonderful! The next time anyone asks why Python 3 is better, I'll just link them to this project's README.
freyir 10y ago
I suspect there's a sudden push for "Python 2.8" from some of the 2.x holdouts because it's becoming increasingly obvious that the wider community is coalescing around 3.x. I feel a bit sorry for people stuck on large Python 2 projects and who can't make the jump, but there's a very vocal minority in this group that wants the rest of the world to be held back along with them.
- oliwarner 10y ago
  For those people genuinely "stuck" I can certainly understand wanting to prolong the life of 2.7 past 2020. It keeps legacy products secure and working without having to retool them onto 3.x, which really is a big job. Why not. The core python team is unhappy keeping it on life support but why couldn't somebody else? But this "2.8" is about adding 3.x language features onto 2.7, essentially declaring a brand new language standard for new development. People who want this aren't saying they don't want to upgrade, they're saying they want to stay on 2.x forever. That seems perversely stubborn to me.
jononor 10y ago
Someone make a Python 3 which can load Python 2 code, to allow for gradual migration.
gaelow 10y ago
NO. No way. It's the second time I see this here. The answer is not a hybrid that is neither 2.7 nor 3.0 compliant. That's just a third, useless standard. Let's just please stick to one standard, preferably the most current from the official ones and start porting/rewriting whatever we need until we need the old one no more. Please.

73 points by bootload 10y ago

deleted 10y ago

[deleted]

The 2.X => 3.X transition really appears to have been bungled here, which is a shame. I really liked Python before I got deeply into the .Net world, but it has become less than enticing with this fragmentation. Meanwhile other languages seem to have taken up the vanguard position, which leaves Python in kind of an awkward position, between the new hotness and the tried-and-true enterprisey ecosystems

TylerE 10y ago
I don't think it's "appears to have been" at this point. Python 3 was released in 2008. Python 3 is now older than Python 2 was on the day Python 3 was released.
copx 10y ago
>The 2.X => 3.X transition really appears to have been bungled here, which is a shame. Obviously, the question is what went wrong. Personally I think the dev team gave users too much time to switch. The Python devs should have only given users one or two years to upgrade. Making it clear that all support for Python 2 would end after that period. Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile. They made this worse by backporting features from Python 3 to Python 2, something they should have never done. Python 2 should not have gotten any new features after the release of Python 3. Python 3 advocates like to blame the users for not upgrading, but I think that is / was simply the result of the actions of the dev team which made staying with Python 2 too comfortable and moving to Python 3 not attractive enough.
- otabdeveloper 10y ago
  No, the problem is that Python 3 sucked, and still sucks. Twisting your user's arms even more painfully won't solve the problem, it will just accelerate users switching away to other languages or forks.
  - scrollaway 10y ago
    There's plenty of problems with Python 3 and the transition, none of them are that "Python 3 sucks". You know that, of course, otherwise you'd have provided an actual claim rather than a generic complaint.
  - throwaway91111 10y ago
    How does python 3 suck? It seems quite pleasant to use for me, and I much prefer the clean bytes/str separation.
- bzz01 10y ago
  > Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile. This is the core issue, but you're putting cart before horse a bit: if there's not much to gain from switching, why would any reasonable person switch? And, most importantly, why is it a problem that needs solving at all?
- frik 10y ago
  Exactly. For language devs. It's always good to learn from mistakes from the past. PHP 6 failed, then PHP stayed with 5.x and moved directly from v5 to v7 - that worked out fine. The Python 2 to 3 is an important lesson as well. Ruby (afaik 1 to 2), dotNet 1 to 2 and 4 to dotNetCore 1, Swift 1 to 2 to 3, ... are several more cases that were rocky for developers.
  - riffraff 10y ago
    AFAIR the messy release for ruby was 1.8 -> 1.9 (the new VM, changes to encodings, OS-level threading etc) but both that change and 1.9->2.0 worked out _much_ better than python 2->3. As I understand it, Matz considers the upgrade strategy until now quite successful, mostly because at the same time breaking changes occurred people got things they wanted (e.g. faster VM) which encouraged them to upgrade. Hence the "ruby 3 will be 3 times faster than ruby 2" idea, that's the carrot that should contrast people's will to not update.
    - sjellis 10y ago
      I suspect that Ruby also benefited from having a comparatively young community. There are folks that used Ruby before Rails, but the majority of Rubyists only started in 2006 or later, so they are used to the faster replacement rate of modern Open Source and didn't have so many legacy codebases to worry about.
- dagw 10y ago
  Another mistake was that when originally released Python 3 did not offer enough shiny new things to convince people that going through the pain of upgrading was worthwhile. Not only that, they effectively took away a lot of vital shiny old things like numpy and django. It was something like 3 years between python 3.0 and the first stable releases of numpy and django with python support. That was 3 years where python 3 was effectively useless to a large number of python developers, and you can lose a lot of momentum in 3 years. Had the core python team gotten together with the teams for numpy, scipy, django and a couple of other big name libraries and coordinated the release of python 3 with versions of all those libraries that would work with python 3, then I imagine things might have gone a lot smoother.
douche 10y ago
I'm curious why this is so downvoted...
- greglindahl 10y ago
  Every single HN thread about Python includes a pointless and repetitive discussion of Python 3 being bungled. I didn't downvote you, but I can see why many others might.
iaml 10y ago
They really should have EOL'ed 2.x much quicker then what we have now. When you have that much time there is really no incentive to ever switch.

frunzales 10y ago

The amount of trolling in that thread is incredible. I don't understand why an average Joe needs to contradict Guido on trademark matters.

scrollaway 10y ago
Because some people are hateful by nature and see Guido as Satan incarnate for "hating Python 2". And no, I'm not exaggerating, you just need to look at the comments: https://github.com/naftaliharris/placeholder/issues/47#issuecomment-266464920 https://github.com/naftaliharris/placeholder/issues/47#issue... I read through that thread the other day and it breaks my heart to know that there are people who think like that. Honestly. On various occasions I've reasoned (and not reasoned) with the most absurd people, there is always some way to understand where the craziest of logic comes from. But here, I'm just sad. And I'm especially sad because I've seen similar comments on HN (even just the other day). So really, this goes out to anyone who works in tech and feels like this either about Python or about any open source project: Treat your FOSS maintainers with some human decency. It's not the first time I say it, and every time I say it there's always some people nodding at this; "oh yes, of course, well who acts like that really?", those same people turning around a week later, flaming Lennart Poettering for whatever software du jour the guy wrote. sighs
- afterburner 10y ago
  Team Red, Team Blue, Team Three, Team Two (no direct relation to political parties intended)
- sfilargi 10y ago
  They should name it Monty. A little humor will help with the tension.
  - BerislavLopac 10y ago
    Or "Parrot".

copx 10y ago

The fork should be called "Lython" as in Legacy Python.

daveguy 10y ago

I'm glad Guido considers this a toy. Anyone interested in helping out the github repo is here: https://github.com/naftaliharris/placeholder https://github.com/naftaliharris/placeholder

didibus 10y ago
He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any problem here. The maintener agreed to change the name. I don't expect this project to exist for very long unless it breaks free, but if it tries to just bring 3 features back to 2, I'm not sure it'll make sense for very long.
- unixhero 10y ago
  The problem is some of the massive python modules that cannot be ported from 2.7 to 3 .x
  - viraptor 10y ago
    Which ones specifically? Many massive ones that held out for a long time are either done or in the process of porting. (twisted, openstack, almost all web frameworks, etc.) PS. https://python3wos.appspot.com/ https://python3wos.appspot.com/ now shows only few packages not marked as compatible from the most popular ones. One group (carbon, graphite, supervisor) are not libraries so they don't really affect others. The other is specific moz* libraries - and they're for Mozilla's internal testing, so nobody else should care that much.
    - unixhero 10y ago
      Yes I was thinking about twisted
  - 10y ago

ram_rar 10y ago

I am afraid that, the python community has messed up 2.x => 3.X transition. Until 3.3, there seemed no incentive to port your codebase to Python 3.X. With golang getting a lot of traction and compiler tools like grumpy (python -> Go), I would rather invest time to transition into golang as apposed to transition to 3.X.

Cyph0n 10y ago
Transitioning from Python to Go isn't as easy as you make it out to be. Good luck finding solid alternatives to the likes of Numpy, scikit-learn, Pandas, SQLAlchemy, BeautifulSoup, Flask etc. Oh, and not to mention the community surrounding these and other popular Python libraries.
- deleted 10y ago
  [deleted]
- tyfon 10y ago
  All of them work in python 3.x too. Well. I'm not sure about flask, it's not one i use personally.
  - notamy 10y ago
    I've been using flask with python 3.6; it seems to be working fine.
  - Cyph0n 10y ago
    I know, but I was addressing the point about migrating to Go.
- ram_rar 10y ago
  Numpy / scipy and scikit-learn are the only things that are holding me back. Apart from that, I think its just a matter of time golang will have similar libraries in its ecosystem. Afaik, for regular CRUD apps golang can pretty much replace whole of python with better performance (in terms of concurrency).

placebo 10y ago

Back when python 3 was introduced and after learning of breaking backward compatibility my first thought was, "good luck with that"... Wanting to create something better is not surprising. What was surprising (to me at least) is not seeing that people don't like change unless they see a really dramatic benefit to what they already have, and clearly see that the advantages to making that change far outweigh the discomfort of the process. Most people have a really hard time changing from something they know, even if it's less than perfect. Actually, even if it sucks. Ask any marketer, salesman, social worker or psychologist and you will see this is not limited to programming languages, and beyond the psychology, change has an economic price that needs to be justified. So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did. I don't know whether to attribute this more to the quality of the language or the energy that went into promoting migration to it, but its current adoption rate to me is a mark of success when one tries to compare it with other attempts to reeducate a well established market.

hueving 10y ago
Yes, the biggest hindrance to python3 is the fact that python2 is a good language. It's very rare to come across a case where you can tell someone, "if you were using python3, this would be so much easier/more performant." Most of the migrations I have seen have been because of a stick rather than a carrot (e.g. this library we depend on is dropping py2 support). It's definitely the case that the move has only been as successful as it has because of the (relatively) unified effort of popular open source library authors to switch common dependencies.
- sametmax 10y ago
  Well, another issue is that there are carrots, but they are tough to sell. I have been using Python 3 for 2 years now in production, and I would never want to go back to Python 2. Benefits include: - less boilerplate. Automatic super(), no object inheritance, yield from, generalized unpacking, keyword only args, less itertools import, no need for __future__, f-srings, etc. Basically my code is shorter and faster to write. - better error handling. This one is big. It is easier to get a bug free Python 3 program. You get exception nesting handling, finer file exception granularity, more safety nets (e.g: no more arbitrary object comparison), better error messages, absolute import by default, regular division by default, etc. As a trainer, Python 3 is so easier to teach. - unicode is no just about u''. You have the "encoding" parameter everywhere by default. Everything default to "utf8" naturally. You don't need the # coding: monbo jumbo. There is no more "auto-casting" of bytes. English native speakers underestimate the value of this. As a European, it's invaluable to me, and it is to the rest of the world that is not using ASCII as their main alphabet. Those are really, really great benefits. But terrible carrots. They don't sell. People want big shinny stickers with "+30% perf" which will never be of used for most projects. While those benefits, I guaranty, are stuff all project benefits from, and you feel them a lot once you get used to them.

vaibhavsagar 10y ago

This is wonderful! The next time anyone asks why Python 3 is better, I'll just link them to this project's README.

freyir 10y ago

I suspect there's a sudden push for "Python 2.8" from some of the 2.x holdouts because it's becoming increasingly obvious that the wider community is coalescing around 3.x. I feel a bit sorry for people stuck on large Python 2 projects and who can't make the jump, but there's a very vocal minority in this group that wants the rest of the world to be held back along with them.

oliwarner 10y ago
For those people genuinely "stuck" I can certainly understand wanting to prolong the life of 2.7 past 2020. It keeps legacy products secure and working without having to retool them onto 3.x, which really is a big job. Why not. The core python team is unhappy keeping it on life support but why couldn't somebody else? But this "2.8" is about adding 3.x language features onto 2.7, essentially declaring a brand new language standard for new development. People who want this aren't saying they don't want to upgrade, they're saying they want to stay on 2.x forever. That seems perversely stubborn to me.

jononor 10y ago

Someone make a Python 3 which can load Python 2 code, to allow for gradual migration.

gaelow 10y ago

NO. No way. It's the second time I see this here. The answer is not a hybrid that is neither 2.7 nor 3.0 compliant. That's just a third, useless standard. Let's just please stick to one standard, preferably the most current from the official ones and start porting/rewriting whatever we need until we need the old one no more. Please.