8 ms·

This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as we

This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.

VeejayRampay 9y ago
The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time.
- ggm 9y ago
  Perl6
  - mateuszf 9y ago
    Perl6 is not as widely used as Python 3. Also it's practically a new language in comparison to Perl5.
  - BjoernKW 9y ago
    Well, they didn't really get away with it. Perl isn't as widely used as it used to be. Besides, in spite of the name Perl6 isn't compatible with Perl5 but rather a completely new language.
    - labster 9y ago
      Perl 6 is a completely new language, but that doesn't mean it's incompatible. Inline::Perl5 provides a rather extensive compatibility layer with Perl 5: https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5
      - peteretep 9y ago
        By this logic, Perl is also compatible with the many other languages for which there are Inline:: modules.
        raiph 9y ago
        The Perl 6 Inline::Perl5 automatically maps Perl 5's syntax, object system semantics, exceptions, etc. to Perl 6's so that Perl 6 users don't in principle have to know about Perl 5, just the logical API of any used module/library/function. I don't think the Perl 5 inlines do this.
- mjburgess 9y ago
  They didnt really "get away with it". But as far as Oracle, for example,doing something similar -- yes, open source languages get more of a pass. Being an open community effort gives you a free-pass to make mistakes because you're methodologically sincere. Decisions are made by, and on behalf of, those who use the systems. Having proprietary interests means you're methodologically insincere: mostly, you sell decisions for the developer but they are mostly for the company.
  - oblio 9y ago
    Also the tech upgrade is free in terms of software license costs. Yes, those are generally dwarfed by time investments for tests, but still.
- sorisos 9y ago
  Many languages seem to suffer from legacy support. C++ and PHP for example. The double standard might be the only way to avoid this!?
  - pjc50 9y ago
    The legacy support is a benefit for people who are still using it. The lesson from both Perl and Python is clear: you cannot remove language features - if you do you're creating a new language which has to start from zero in adoption.
    - b2gills 9y ago
      Perl 6 removes very few language features. About the only notable ones I can think of is fork and format. Since Perl 6 has built-in multithreading, fork is not needed. And hardly anyone uses format anymore (it is great for directly printing to a line printer). What Perl 6 did is change the syntax for various features of Perl 5; while adding a lot of new features.
- Y_Y 9y ago
  Not to mention the loss of tuple unpacking in function signatures. Even if i felt morally wrong about it, for the last few years I've been writing python2 with a few `from __future__`s at the top since it was fastest and most featureful and had all the libraries.
  - ChrisSD 9y ago
    I'm not sure that tuple unpacking in function signatures is any great loss. It's a feature I hardly ever saw used and if you do need to unpack an argument then you can do so in the first line of the function's code.
    - dx034 9y ago
      I saw it used a lot and it caused hours of rewrites to get libraries python3 ready. It's one of those things where I wonder why they didn't just depreciate it for another few iterations, allowing scripts to be changed over time.
      - ChrisSD 9y ago
        The 2to3 tool will rewrite it automatically. It's not something that requires manual intervention.
        dralley 9y ago
        Oh ho ho, it is _not_ that simple. Any code with a lot of assumptions about text encoding or integer division is going to be terribly broken after 2to3. It very much does require manual intervention unless you're doing very simple scripts.
        ChrisSD 9y ago
        Sure but the 2to3 tool allows you to run the tuple_params fixer on its own. Text encoding and integer division are separate issues and have nothing to do with unpacking tuples in function arguments. My point in this conversation has been that this feature doesn't require manual rewrites. And I'd add that in any case the deprecation period for python 2 will have been 12 years once Python 2 reaches EOL. That's plenty of time to update a code base.
- nothrabannosir 9y ago
  Double standards by whom?? Every other article or comment I’ve read since basically py3+1y has been incredibly negative about it. The only positive news about Python, recently, seems from people who were not around since the py2 days. Data science is where it’s at now, but it used to be massive and ubiquitous. Golang came at a time where public perception of Python was down the drain, and ate a big chunk of its lunch.
  - samastur 9y ago
    I've been around since ~1.5 and have no idea what you are talking about. I suspect our perception is very much coloured by where and whom you are hanging out with. Agree that there was never a shortage of negative articles about py2/py3 transition. Fairly certain Golang success was down to its advantages more than Python's perception who's use has grown through all this time.
  - goatlover 9y ago
    > and ate a big chunk of its lunch Pretty sure that's not true. Golang might have taken some from Python web frameworks or command line tools, but that's about it. Python's popularity in scientific computing has only grown over time, and that encompasses a lot of fields and users, not just data science.
  - ianamartin 9y ago
    My interpretation of the usage share is that Golang ate a bunch of lunch that would've otherwise gone to Python. That is, people moving from other languages (Perl, PhP) to something else for various reasons. Absent Go, I suspect many current Gophers would've landed on Python. So in a sense, Python lost people to Go. But I've never seen anything to indicate that there was a large migration from Python to Go, and certainly not because of 2 to 3 or public perception--whatever that means in the context of a programming language. Python 2 is still the mainstay for Data Scientists. I've seen more resistance to moving to 3 there than almost anywhere. Which is pretty funny because it's the easiest code to port assuming your data science libs support 3 (and all the big ones do.) I think it's more accurate to say that Go ended up with some of Python's potential mindshare, not that it stole a significant amount of existing mindshare.
- mhd 9y ago
  Wasn't there a big brouhaha over the change from VB6 to VB.Net? The big difference there is that if it's ordained from your corporate overlords, you have little choice, whereas you feel like you've got a bigger right to complain when it's "just" coming from the BDFL.
  - umanwizard 9y ago
    VB.NET is a totally new language almost unrelated to VB6. That’s like talking about C vs C++, not py2 vs py3.
    - toyg 9y ago
      Calling it a “New language” flatters Vb.net. In reality, it was a “marketing compatibility shim” on top of C# to help VB developers acclimatise to the CLR.
  - michaelt 9y ago
    As VB6 is compiled, you don't need your users to have a particular interpreter version installed.
    - ajdlinux 9y ago
      I do remember the good old days of having to make sure you had MSVBVM50.DLL or MSVBVM60.DLL in the right place...
      - pjmlp 9y ago
        It is no different than ensuring you have the right libc.so in place.
- ceronman 9y ago
  What do you mean by double standard? Everyone in the community, including the core developers, acknowledge that the 2 to 3 story was full of mistakes. They have promised not to make it again. And they took some actions to remedy the problems, and that's why Python 3 is finally succeeding. I recommend this presentation by Victor Stinner at FOSDEM 2018 which talks about it: https://fosdem.org/2018/schedule/event/python3/ https://fosdem.org/2018/schedule/event/python3/
  - VeejayRampay 9y ago
    The double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.
    - stealthcat 9y ago
      Ruby took off because of Rails. Rails' convention over configuration defies Ruby's flexible nature. It feels more like Python. People prefer dumb unambiguous code over clever code. That's why Python and Rails succeeded
      - ComputerGuru 9y ago
        “Dumb, unambiguous code” does not rely on magic conventions that change with the whim of the framework developer.
    - toyg 9y ago
      That massive chip on your shoulder is weighing you down. If you really think something like that is happening (big if - I’ve gone through so many py3 flames...), the only answer is: because people love the language SO DAMN MUCH that they will overlook its warts. And the next logical step would be to find out how an independent research project, staffed mostly by volunteers and without a marketing budget of any sort (and not running in every browser nor shipping preinstalled on the most popular operating system), ended up with this sort of mindshare. There might be some good lessons there.
- hyperpallium 9y ago
  I think it's the opposite. When other languages make incompatible changes, they have serious problems (e.g perl6). Previous versions of python were back-compatible. Java versions stress back-compatibility. I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Python has done everything possible to avoid this fate, by maintaining 2.7. And I'm not even convinced python has gotten away with yet (e.g. kalite, offline khan academy, needs 2.7). RHEL may end up reversing this. Give it another ten years! Amd the Enterprize is the most back-compatible thing you've ever seen. This change is going to break lots of code, and they will reverse or lose customers.
  - Xylakant 9y ago
    > When other languages make incompatible changes, they have serious problems (e.g perl6). Counter-example: The ruby 1.8 -> 1.9 -> 2.0 upgrade path. 1.9 introduced the whole encoding system, which was a major update at the time. It did break a lot of libraries that handled strings. Still, the change went over fairly quickly, partly because major players in the ruby world (rails) adopted the change. The update also brought clear benefits and it was clearly marked that 1.8 was going to go out of support. There are still some stragglers (centos 6, I'm looking in your direction), but it's clearly accepted that ruby 2.x is the standard that you should be writing code for.
  - Steeeve 9y ago
    > Java versions stress back-compatibility. You reminded me of the java version incompatibility nightmares that once littered the enterprise landscape. If they do that now, it's because their history includes perhaps the worst set of incompatibility jumps of any popular language.
  - irishsultan 9y ago
    > I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Ruby qualifies, I'd say. From 1.8 -> 1.9 there were syntax changes, changes to how strings worked and so on. Code written for 1.8 would not in general work on 1.9 and the other way around. While it was possible (sometimes with some extra if statements) to write code that worked on both versions I would definitely call it an incompatible, code-breaking upgrade.
- jnwatson 9y ago
  I guess you haven’t looked at Swift. All 4 major versions are very incompatible.
  - deleted 9y ago
    [deleted]
  - imtringued 9y ago
    It's still a young language and doesn't have as much legacy codebases as python.
    - tjalfi 9y ago
      Xcode also has tooling support that will handle a lot of the language conversion for you.
- est 9y ago
  > No other living language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time FTFY. Just think about Perl6, Lua5.3 and VB.NET I am pretty sure somewhere in this world a miserable soul has to maintain a Ruby1.8 codebase.
- canofmoi 9y ago
  Quite the opposite. Python had deep problems that could simply not be fixed without BC breaks. The decision was made, and in hindsight it was the correct decision by Guido and other core devs. Look at PHP, and look what a total cluster of madness the language has become.
  - oblio 9y ago
    I think Python 3 was not brave enough, to be honest, to future proof Python: * an optional type system without hacks was not introduced (types in comments, really?) * the GIL was not removed or at least a solid parallelism story was not included, one that would allow Python to use all cores on a system while sharing, if needed, memory * no true performance improving changes were made; by this I mean stuff that improve performance by an order of magnitude; Python is still way too dynamic and this basically sunk Google's Unladen Swallow and Dropbox's Pyston, at least in terms of worldwide adoption I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX. Python was a bit lucky to catch the ML train but who knows how long this will last. And Go, Kotlin, Typescript, Swift, Julia, Rust even are improving their ergonomics and edging towards Python's core competency.
    - jononor 9y ago
      Since Python 3.5 (3 years ago) type hints are part of the core syntax. Don't need to put them in comments. https://www.python.org/dev/peps/pep-0484/#type-definition-syntax https://www.python.org/dev/peps/pep-0484/#type-definition-sy...
      - tobltobs 9y ago
        > a_list = [] # type: List[T] How do you do that with out a comment?
        Osmium 9y ago
        > a_list: List[T] = []
- pbalau 9y ago
  Php3 and php4? Php4 and 5? Then I've lost contact with pure php
raverbashing 9y ago
Got a source for the performance regressions? Some things are faster in Python 3 than 2 "Most popular" packages, which ones? Most moved a long time ago to Python 3
- jhasse 9y ago
  > "Most popular" packages, which ones? Most moved a long time ago to Python 3 http://py3readiness.org/ http://py3readiness.org/
  - raverbashing 9y ago
    Thanks for proving my point There's Fabric3, MySQL libs that work with Python3 (and Django), futures are a backport of a feature from Python3, uWSGI and BeautifulSoup might be worrying but the site shows mostly green At this point if the library hasn't been ported to Py3, someone else would have done it for you or abandoned it. Edit: Thanks for the updates!
    - jhasse 9y ago
      I think ansible is a big one for RHEL though.
      - evgen 9y ago
        Ansible works just fine on python3 for both local and remote actions. You need to explicitly tell it to use python3 at the moment, but this will go away eventually.
        geerlingguy 9y ago
        There are a couple modules with options that break in a Python 3 environment, but that number is I think in the single digits now. I’m very close to switching all my Ansible masters to 3 finally.
    - detaro 9y ago
Steeeve 9y ago
On the one hand... This is 3 years after the first time I saw a Gentoo python3 only environment. On the other Python2 support will go away when the community is done with Python2. And that process goes a lot slower than I think most people appreciate. Still, a big vendor changing their defaults helps a good deal with the push.
Narann 9y ago
> most popular packages are now compatible with Python 3 I often see this but I think it's a perception from the Internet/web world. I work for CGI, all (I'm not kidding) our softwares (we have many) are 2.7. You will never see them used "on the web/Internet/forum/network" place but the day-to-day job of millions of peoples in the industry is 2.7. And we are a tiny focused industry. So I'm sure there is many other industries like us which are 2.7 that you will never heard of. That's why "most popular" mean nothing once you take how Python is use as a whole. We don't use any of this web/Internet/network "popular" packages. I'm not saying Python shouldn't move on. I'm just trying to argue against this "most popular packages" while millions of us, even if you don't know it, us none of those.
- notspanishflu 9y ago
  I know some "tiny focused industry" that's still using DOS.
  - xab9 9y ago
    I see a DOS application running on XP all the time I go and visit the local doctor (social healthcare, regional center).
    - pjmlp 9y ago
      Given the use case, I bet it was most likely written in Clipper.
      - xab9 9y ago
        Probably, friend of mine seen a dbase one lately...
- audiolion 9y ago
  If you arent using the packages that most people use, and decided to roll your own, then it is on you to upgrade. Not seeing the issue here of course your custom niche libraries havent been upgraded if you havent been diligent. The py2 end of life is supposed to give your manager hard reasons to switch. But if you never use pypi packages and dont interact with the web, you dont need to upgrade, as you don't need to install packages that might be 3 only and you dont have potential for security vulnerabilities.
ThatHNGuy 9y ago
i can feel about the same time for Java 8 to Java 11, where 9 and 10 are transitional and with a really low level of engagement, especially for thrid-party libraries, kicking the jar-hell again
lloeki 9y ago
> Although it still took way too long, if you consider Python 3.0 was released about 10 years ago Somehow, it was the plan[0]. I feel like I wrote about that extensively already way too many times[1]. [0]: (2016) https://news.ycombinator.com/item?id=11502844 https://news.ycombinator.com/item?id=11502844 [1]: (2012) https://news.ycombinator.com/item?id=4569440 https://news.ycombinator.com/item?id=4569440
- maxerickson 9y ago
  I think one of the biggest mistakes is that 3.0 didn't have "PREVIEW RELEASE" right in the name. People started counting the day it was released, meanwhile the developers didn't have any expectation that (many) people would use it in production.
  - collinmanderson 9y ago
    Right, the way I look at it: 2008-2012 3.x itself being usable. 2012-2016 Libraries getting 3.x support. 2016-2020 Applications geting 3.x support (trac, samba, ansible, etc)
bitL 9y ago
You forgot one: - 90% of business code is written in Python 2.x
- consp 9y ago
  We've switched from 2.7 to 3.4 (and upwards to 3.5, 3.6) in about a month or so. It delayed some deployments but nothing serious. If you do it step-by-step it's not that hard. The worst part was str/binary conversions but afterwards everything was a lot easier and better to maintain. If your company is big enough you should maintain and keep it up-to-date, not "it just works"(TM) and hope for the best after 10 years. The death of 2.7 was already in the air for years.
  - bitL 9y ago
    It's not that hard unless you had some very advanced code utilizing Python 2 internals that were significantly changed in Python 3. However, conversion takes a lot of time and if something works, why should you be forced to change it?
    - gravis7777 9y ago
      Because non-IT users (your customers) are sick and tired of apps from 2000 that run clunky and ugly because someone is "forcing you change it" (aka doing your job) and you don't feel like it. Yes,
      - deleted 9y ago
        [deleted]
      - bitL 9y ago
        I know some extremely well-written apps from 2000 without trendy obfuscating flat interface, and many trendy albeit unusable monstrosities from the past 3 years. What kind of argument did you make?
      - BuckRogers 9y ago
        Embracing pure technical churn is no ones job. That's why Python3 is viewed as a problem by so many. People embrace true technical innovation, which it is not.
paulie_a 9y ago
About as well, but in a number of cases signicantly worse. I am not saying people shouldn't upgrade, but it's not without issues.
compuguy 9y ago
Ansible still doesn't support Python 3....
- takeda 9y ago
  Ansible is an application not a library so it is not a problem. Python allows to install multiple versions at the same time, for example you can have Python 2.7, 3.3, 3.4, 3.5 and 3.6 installed side by side and all will work fine without issues. So you can have Python 2.7 installed for Ansible and 3.6 for your application.
- arc_of_descent 9y ago
  I use Ansible via the API. I want to do it Python 3. I moved the ansible directory from /usr/local/python2 ... to /usr/local/python3 and then squashed out any bugs by hand. It works! I'm using Ansible via the API in Python 3!
autokad 9y ago
> "- Python 3.7 performs about as well as 2.7 with future release expected to be better" are you sure on that? my laptop (2.7 ghz 4 cores, 16gb ram) would fall behind my desktop (3.8 ghz 6 cores, 64 gb ram) because it would be paging things in and out of ram, but once the models started running (like XGBOOST), py2x was about twice as fast. I am not stating this with difinity, because I was not trying to benchmark the two. Just that I casually noted my laptop would always finnish running the same code in 1 hour vs over 2 hours on my desktop.
m-p-3 9y ago
> - most popular packages are now compatible with Python 3 And if one isn't, then it's another incentive to update it or abandon it.
pbreit 9y ago
Does this whole thing qualify as a "debacle"? Why not a stronger effort at backwards compatibility? Certainly not to maintain performance, correct?
metaobject 9y ago
Why would previous versions of Python3 (e.g., 3.5, 3.6) not perform as well as 2.7? What about Python3 makes it slower? Is it a language design issue? We’re in the process of migrating several keras/TensorFlow-based projects to 3.6, and I’m struggling to get my emacs environment setup to handle Python 2 and 3 code simultaneously.

VeejayRampay 9y ago

The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time.

ggm 9y ago
Perl6
- mateuszf 9y ago
  Perl6 is not as widely used as Python 3. Also it's practically a new language in comparison to Perl5.
- BjoernKW 9y ago
  Well, they didn't really get away with it. Perl isn't as widely used as it used to be. Besides, in spite of the name Perl6 isn't compatible with Perl5 but rather a completely new language.
  - labster 9y ago
    Perl 6 is a completely new language, but that doesn't mean it's incompatible. Inline::Perl5 provides a rather extensive compatibility layer with Perl 5: https://github.com/niner/Inline-Perl5 https://github.com/niner/Inline-Perl5
    - peteretep 9y ago
      By this logic, Perl is also compatible with the many other languages for which there are Inline:: modules.
      - raiph 9y ago
        The Perl 6 Inline::Perl5 automatically maps Perl 5's syntax, object system semantics, exceptions, etc. to Perl 6's so that Perl 6 users don't in principle have to know about Perl 5, just the logical API of any used module/library/function. I don't think the Perl 5 inlines do this.
mjburgess 9y ago
They didnt really "get away with it". But as far as Oracle, for example,doing something similar -- yes, open source languages get more of a pass. Being an open community effort gives you a free-pass to make mistakes because you're methodologically sincere. Decisions are made by, and on behalf of, those who use the systems. Having proprietary interests means you're methodologically insincere: mostly, you sell decisions for the developer but they are mostly for the company.
- oblio 9y ago
  Also the tech upgrade is free in terms of software license costs. Yes, those are generally dwarfed by time investments for tests, but still.
sorisos 9y ago
Many languages seem to suffer from legacy support. C++ and PHP for example. The double standard might be the only way to avoid this!?
- pjc50 9y ago
  The legacy support is a benefit for people who are still using it. The lesson from both Perl and Python is clear: you cannot remove language features - if you do you're creating a new language which has to start from zero in adoption.
  - b2gills 9y ago
    Perl 6 removes very few language features. About the only notable ones I can think of is fork and format. Since Perl 6 has built-in multithreading, fork is not needed. And hardly anyone uses format anymore (it is great for directly printing to a line printer). What Perl 6 did is change the syntax for various features of Perl 5; while adding a lot of new features.
Y_Y 9y ago
Not to mention the loss of tuple unpacking in function signatures. Even if i felt morally wrong about it, for the last few years I've been writing python2 with a few `from __future__`s at the top since it was fastest and most featureful and had all the libraries.
- ChrisSD 9y ago
  I'm not sure that tuple unpacking in function signatures is any great loss. It's a feature I hardly ever saw used and if you do need to unpack an argument then you can do so in the first line of the function's code.
  - dx034 9y ago
    I saw it used a lot and it caused hours of rewrites to get libraries python3 ready. It's one of those things where I wonder why they didn't just depreciate it for another few iterations, allowing scripts to be changed over time.
    - ChrisSD 9y ago
      The 2to3 tool will rewrite it automatically. It's not something that requires manual intervention.
      - dralley 9y ago
        Oh ho ho, it is _not_ that simple. Any code with a lot of assumptions about text encoding or integer division is going to be terribly broken after 2to3. It very much does require manual intervention unless you're doing very simple scripts.
        ChrisSD 9y ago
        Sure but the 2to3 tool allows you to run the tuple_params fixer on its own. Text encoding and integer division are separate issues and have nothing to do with unpacking tuples in function arguments. My point in this conversation has been that this feature doesn't require manual rewrites. And I'd add that in any case the deprecation period for python 2 will have been 12 years once Python 2 reaches EOL. That's plenty of time to update a code base.
nothrabannosir 9y ago
Double standards by whom?? Every other article or comment I’ve read since basically py3+1y has been incredibly negative about it. The only positive news about Python, recently, seems from people who were not around since the py2 days. Data science is where it’s at now, but it used to be massive and ubiquitous. Golang came at a time where public perception of Python was down the drain, and ate a big chunk of its lunch.
- samastur 9y ago
  I've been around since ~1.5 and have no idea what you are talking about. I suspect our perception is very much coloured by where and whom you are hanging out with. Agree that there was never a shortage of negative articles about py2/py3 transition. Fairly certain Golang success was down to its advantages more than Python's perception who's use has grown through all this time.
- goatlover 9y ago
  > and ate a big chunk of its lunch Pretty sure that's not true. Golang might have taken some from Python web frameworks or command line tools, but that's about it. Python's popularity in scientific computing has only grown over time, and that encompasses a lot of fields and users, not just data science.
- ianamartin 9y ago
  My interpretation of the usage share is that Golang ate a bunch of lunch that would've otherwise gone to Python. That is, people moving from other languages (Perl, PhP) to something else for various reasons. Absent Go, I suspect many current Gophers would've landed on Python. So in a sense, Python lost people to Go. But I've never seen anything to indicate that there was a large migration from Python to Go, and certainly not because of 2 to 3 or public perception--whatever that means in the context of a programming language. Python 2 is still the mainstay for Data Scientists. I've seen more resistance to moving to 3 there than almost anywhere. Which is pretty funny because it's the easiest code to port assuming your data science libs support 3 (and all the big ones do.) I think it's more accurate to say that Go ended up with some of Python's potential mindshare, not that it stole a significant amount of existing mindshare.
mhd 9y ago
Wasn't there a big brouhaha over the change from VB6 to VB.Net? The big difference there is that if it's ordained from your corporate overlords, you have little choice, whereas you feel like you've got a bigger right to complain when it's "just" coming from the BDFL.
- umanwizard 9y ago
  VB.NET is a totally new language almost unrelated to VB6. That’s like talking about C vs C++, not py2 vs py3.
  - toyg 9y ago
    Calling it a “New language” flatters Vb.net. In reality, it was a “marketing compatibility shim” on top of C# to help VB developers acclimatise to the CLR.
- michaelt 9y ago
  As VB6 is compiled, you don't need your users to have a particular interpreter version installed.
  - ajdlinux 9y ago
    I do remember the good old days of having to make sure you had MSVBVM50.DLL or MSVBVM60.DLL in the right place...
    - pjmlp 9y ago
      It is no different than ensuring you have the right libc.so in place.
ceronman 9y ago
What do you mean by double standard? Everyone in the community, including the core developers, acknowledge that the 2 to 3 story was full of mistakes. They have promised not to make it again. And they took some actions to remedy the problems, and that's why Python 3 is finally succeeding. I recommend this presentation by Victor Stinner at FOSDEM 2018 which talks about it: https://fosdem.org/2018/schedule/event/python3/ https://fosdem.org/2018/schedule/event/python3/
- VeejayRampay 9y ago
  The double standard is that people still stick to Python despite those problems. If we're being honest and all conspiracy aside, imagine the same story for Ruby (a very similar language in terms of capability, features and performance), everyone would be laughing at them and the language would be pulling a Perl right now.
  - stealthcat 9y ago
    Ruby took off because of Rails. Rails' convention over configuration defies Ruby's flexible nature. It feels more like Python. People prefer dumb unambiguous code over clever code. That's why Python and Rails succeeded
    - ComputerGuru 9y ago
      “Dumb, unambiguous code” does not rely on magic conventions that change with the whim of the framework developer.
  - toyg 9y ago
    That massive chip on your shoulder is weighing you down. If you really think something like that is happening (big if - I’ve gone through so many py3 flames...), the only answer is: because people love the language SO DAMN MUCH that they will overlook its warts. And the next logical step would be to find out how an independent research project, staffed mostly by volunteers and without a marketing budget of any sort (and not running in every browser nor shipping preinstalled on the most popular operating system), ended up with this sort of mindshare. There might be some good lessons there.
hyperpallium 9y ago
I think it's the opposite. When other languages make incompatible changes, they have serious problems (e.g perl6). Previous versions of python were back-compatible. Java versions stress back-compatibility. I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Python has done everything possible to avoid this fate, by maintaining 2.7. And I'm not even convinced python has gotten away with yet (e.g. kalite, offline khan academy, needs 2.7). RHEL may end up reversing this. Give it another ten years! Amd the Enterprize is the most back-compatible thing you've ever seen. This change is going to break lots of code, and they will reverse or lose customers.
- Xylakant 9y ago
  > When other languages make incompatible changes, they have serious problems (e.g perl6). Counter-example: The ruby 1.8 -> 1.9 -> 2.0 upgrade path. 1.9 introduced the whole encoding system, which was a major update at the time. It did break a lot of libraries that handled strings. Still, the change went over fairly quickly, partly because major players in the ruby world (rails) adopted the change. The update also brought clear benefits and it was clearly marked that 1.8 was going to go out of support. There are still some stragglers (centos 6, I'm looking in your direction), but it's clearly accepted that ruby 2.x is the standard that you should be writing code for.
- Steeeve 9y ago
  > Java versions stress back-compatibility. You reminded me of the java version incompatibility nightmares that once littered the enterprise landscape. If they do that now, it's because their history includes perhaps the worst set of incompatibility jumps of any popular language.
- irishsultan 9y ago
  > I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Ruby qualifies, I'd say. From 1.8 -> 1.9 there were syntax changes, changes to how strings worked and so on. Code written for 1.8 would not in general work on 1.9 and the other way around. While it was possible (sometimes with some extra if statements) to write code that worked on both versions I would definitely call it an incompatible, code-breaking upgrade.
jnwatson 9y ago
I guess you haven’t looked at Swift. All 4 major versions are very incompatible.
- deleted 9y ago
  [deleted]
- imtringued 9y ago
  It's still a young language and doesn't have as much legacy codebases as python.
  - tjalfi 9y ago
    Xcode also has tooling support that will handle a lot of the language conversion for you.
est 9y ago
> No other living language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time FTFY. Just think about Perl6, Lua5.3 and VB.NET I am pretty sure somewhere in this world a miserable soul has to maintain a Ruby1.8 codebase.
canofmoi 9y ago
Quite the opposite. Python had deep problems that could simply not be fixed without BC breaks. The decision was made, and in hindsight it was the correct decision by Guido and other core devs. Look at PHP, and look what a total cluster of madness the language has become.
- oblio 9y ago
  I think Python 3 was not brave enough, to be honest, to future proof Python: * an optional type system without hacks was not introduced (types in comments, really?) * the GIL was not removed or at least a solid parallelism story was not included, one that would allow Python to use all cores on a system while sharing, if needed, memory * no true performance improving changes were made; by this I mean stuff that improve performance by an order of magnitude; Python is still way too dynamic and this basically sunk Google's Unladen Swallow and Dropbox's Pyston, at least in terms of worldwide adoption I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX. Python was a bit lucky to catch the ML train but who knows how long this will last. And Go, Kotlin, Typescript, Swift, Julia, Rust even are improving their ergonomics and edging towards Python's core competency.
  - jononor 9y ago
    Since Python 3.5 (3 years ago) type hints are part of the core syntax. Don't need to put them in comments. https://www.python.org/dev/peps/pep-0484/#type-definition-syntax https://www.python.org/dev/peps/pep-0484/#type-definition-sy...
    - tobltobs 9y ago
      > a_list = [] # type: List[T] How do you do that with out a comment?
      - Osmium 9y ago
        > a_list: List[T] = []
pbalau 9y ago
Php3 and php4? Php4 and 5? Then I've lost contact with pure php

raverbashing 9y ago

Got a source for the performance regressions? Some things are faster in Python 3 than 2 "Most popular" packages, which ones? Most moved a long time ago to Python 3

jhasse 9y ago
> "Most popular" packages, which ones? Most moved a long time ago to Python 3 http://py3readiness.org/ http://py3readiness.org/
- raverbashing 9y ago
  Thanks for proving my point There's Fabric3, MySQL libs that work with Python3 (and Django), futures are a backport of a feature from Python3, uWSGI and BeautifulSoup might be worrying but the site shows mostly green At this point if the library hasn't been ported to Py3, someone else would have done it for you or abandoned it. Edit: Thanks for the updates!
  - jhasse 9y ago
    I think ansible is a big one for RHEL though.
    - evgen 9y ago
      Ansible works just fine on python3 for both local and remote actions. You need to explicitly tell it to use python3 at the moment, but this will go away eventually.
      - geerlingguy 9y ago
        There are a couple modules with options that break in a Python 3 environment, but that number is I think in the single digits now. I’m very close to switching all my Ansible masters to 3 finally.
  - detaro 9y ago

Steeeve 9y ago

On the one hand... This is 3 years after the first time I saw a Gentoo python3 only environment. On the other Python2 support will go away when the community is done with Python2. And that process goes a lot slower than I think most people appreciate. Still, a big vendor changing their defaults helps a good deal with the push.

Narann 9y ago

> most popular packages are now compatible with Python 3 I often see this but I think it's a perception from the Internet/web world. I work for CGI, all (I'm not kidding) our softwares (we have many) are 2.7. You will never see them used "on the web/Internet/forum/network" place but the day-to-day job of millions of peoples in the industry is 2.7. And we are a tiny focused industry. So I'm sure there is many other industries like us which are 2.7 that you will never heard of. That's why "most popular" mean nothing once you take how Python is use as a whole. We don't use any of this web/Internet/network "popular" packages. I'm not saying Python shouldn't move on. I'm just trying to argue against this "most popular packages" while millions of us, even if you don't know it, us none of those.

notspanishflu 9y ago
I know some "tiny focused industry" that's still using DOS.
- xab9 9y ago
  I see a DOS application running on XP all the time I go and visit the local doctor (social healthcare, regional center).
  - pjmlp 9y ago
    Given the use case, I bet it was most likely written in Clipper.
    - xab9 9y ago
      Probably, friend of mine seen a dbase one lately...
audiolion 9y ago
If you arent using the packages that most people use, and decided to roll your own, then it is on you to upgrade. Not seeing the issue here of course your custom niche libraries havent been upgraded if you havent been diligent. The py2 end of life is supposed to give your manager hard reasons to switch. But if you never use pypi packages and dont interact with the web, you dont need to upgrade, as you don't need to install packages that might be 3 only and you dont have potential for security vulnerabilities.

ThatHNGuy 9y ago

i can feel about the same time for Java 8 to Java 11, where 9 and 10 are transitional and with a really low level of engagement, especially for thrid-party libraries, kicking the jar-hell again

lloeki 9y ago

> Although it still took way too long, if you consider Python 3.0 was released about 10 years ago Somehow, it was the plan[0]. I feel like I wrote about that extensively already way too many times[1]. [0]: (2016) https://news.ycombinator.com/item?id=11502844 https://news.ycombinator.com/item?id=11502844 [1]: (2012) https://news.ycombinator.com/item?id=4569440 https://news.ycombinator.com/item?id=4569440

maxerickson 9y ago
I think one of the biggest mistakes is that 3.0 didn't have "PREVIEW RELEASE" right in the name. People started counting the day it was released, meanwhile the developers didn't have any expectation that (many) people would use it in production.
- collinmanderson 9y ago
  Right, the way I look at it: 2008-2012 3.x itself being usable. 2012-2016 Libraries getting 3.x support. 2016-2020 Applications geting 3.x support (trac, samba, ansible, etc)

bitL 9y ago

You forgot one: - 90% of business code is written in Python 2.x

consp 9y ago
We've switched from 2.7 to 3.4 (and upwards to 3.5, 3.6) in about a month or so. It delayed some deployments but nothing serious. If you do it step-by-step it's not that hard. The worst part was str/binary conversions but afterwards everything was a lot easier and better to maintain. If your company is big enough you should maintain and keep it up-to-date, not "it just works"(TM) and hope for the best after 10 years. The death of 2.7 was already in the air for years.
- bitL 9y ago
  It's not that hard unless you had some very advanced code utilizing Python 2 internals that were significantly changed in Python 3. However, conversion takes a lot of time and if something works, why should you be forced to change it?
  - gravis7777 9y ago
    Because non-IT users (your customers) are sick and tired of apps from 2000 that run clunky and ugly because someone is "forcing you change it" (aka doing your job) and you don't feel like it. Yes,
    - deleted 9y ago
      [deleted]
    - bitL 9y ago
      I know some extremely well-written apps from 2000 without trendy obfuscating flat interface, and many trendy albeit unusable monstrosities from the past 3 years. What kind of argument did you make?
    - BuckRogers 9y ago
      Embracing pure technical churn is no ones job. That's why Python3 is viewed as a problem by so many. People embrace true technical innovation, which it is not.

paulie_a 9y ago

About as well, but in a number of cases signicantly worse. I am not saying people shouldn't upgrade, but it's not without issues.

compuguy 9y ago

Ansible still doesn't support Python 3....

takeda 9y ago
Ansible is an application not a library so it is not a problem. Python allows to install multiple versions at the same time, for example you can have Python 2.7, 3.3, 3.4, 3.5 and 3.6 installed side by side and all will work fine without issues. So you can have Python 2.7 installed for Ansible and 3.6 for your application.
arc_of_descent 9y ago
I use Ansible via the API. I want to do it Python 3. I moved the ansible directory from /usr/local/python2 ... to /usr/local/python3 and then squashed out any bugs by hand. It works! I'm using Ansible via the API in Python 3!

autokad 9y ago

> "- Python 3.7 performs about as well as 2.7 with future release expected to be better" are you sure on that? my laptop (2.7 ghz 4 cores, 16gb ram) would fall behind my desktop (3.8 ghz 6 cores, 64 gb ram) because it would be paging things in and out of ram, but once the models started running (like XGBOOST), py2x was about twice as fast. I am not stating this with difinity, because I was not trying to benchmark the two. Just that I casually noted my laptop would always finnish running the same code in 1 hour vs over 2 hours on my desktop.

m-p-3 9y ago

> - most popular packages are now compatible with Python 3 And if one isn't, then it's another incentive to update it or abandon it.

pbreit 9y ago

Does this whole thing qualify as a "debacle"? Why not a stronger effort at backwards compatibility? Certainly not to maintain performance, correct?

metaobject 9y ago

Why would previous versions of Python3 (e.g., 3.5, 3.6) not perform as well as 2.7? What about Python3 makes it slower? Is it a language design issue? We’re in the process of migrating several keras/TensorFlow-based projects to 3.6, and I’m struggling to get my emacs environment setup to handle Python 2 and 3 code simultaneously.