44 ms·

Sunsetting Python 2

• jitl 7y ago
  At last...
• coldtea 7y ago
  >If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you. Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team if just security fixes are involved... Not to mention paid FOSS developers at places like RedHat, who want to keep supporting their LTS and enterprise customers...
  • marsokod 7y ago
    No, the benefit of FOSS is that if the group developing a product does not support it anymore, you are free to fork it and support it yourself. And I am sure we will see a fair share of people doing that. What I am not sure is of anyone doing so will have the shoulders to actually support it. Python 2.7 was released 1 decade ago. That's quite a long transition time.
    • brobdingnagians 7y ago
      Tongue in cheek comment; C was released 47 years ago and is still supported... but then again, that shows a very different philosophy between system languages and scripting languages.
      • vkazanov 7y ago
        Not really. :-) ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.
        • brobdingnagians 7y ago
          touché :)
        • jacquesm 7y ago
          Nonsense. I just compiled a pretty large project from the stone age using a modern day compiler. It required a few lines of change in all to make it compile and it ran the first time it compiled. C has many warts and design errors but they got the portability bit down quite well, the biggest problems you will run into are assumptions by programmers rarely assumptions by the designers of the language. One major thing lots of people tripped up over was endianness (sp?).
          • SiempreViernes 7y ago
            That you could easily port an old C code to modern compilers seems doesn't seem to be in contradiction to the statement that old code will not compile as is.
            • jacquesm 7y ago
              A couple of lines change does not qualify as a port to me. It was less of a change than from one minor release of a modern language to another.
              • vkazanov 7y ago
                Prior to the ANSI standard there were many C compilers on different machines with different architectures. Some compilers included support for architecture-specific things, like segmented memory, etc. Others allowed to do cross-function gotos. Types were not very well defined. Event the original language grammar from the book is only useful as an idea of what the language should be like, not as a proper syntax definition, I am not even talking about semantics here. The code I had to deal with (written for 16-bit x86) had to be rewritten, it was definitely not a "fix-here-and-there" thing. It was fine, written by reasonable programmer and completely readable so I was able to understand and rewrite it in a week. You probably were very lucky with that project of yours. Even the way we have it nowadays C is... hard to formalise.
      • CogitoCogito 7y ago
        That's not really a fair comparison. Python 2 probably _will_ be supported for decades to come, just not necessarily by the PSF. I'm sure that 99% of people and organizations supporting C 40 years ago do _not_ support C today.
      • lstamour 7y ago
        C is also a living language to some degree: http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log.htm http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log... It still requires dialect selection: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/C-Dialect-Options.html#index-std-1 https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/C-Dialect-Optio... http://releases.llvm.org/7.0.0/tools/clang/docs/UsersManual.html#differences-between-various-standard-modes http://releases.llvm.org/7.0.0/tools/clang/docs/UsersManual.... Not to mention that a system library is only as portable as the code you write for it, since inherently there’s usually a very small standard library of functionality that can be assumed across platforms. And all the support for systems generally rests on the system developer shipping support with C headers, etc. Now it could be argued that C dialects are far more compatible with each other than Python 2 to Python 3, it could also be argued that linkers allow for code targeting one dialect to call code compiled for another dialect... Once you go down that rabbit hole, though, there’s an argument that as most scripting languages are basically VMs with JIT compilation, then just like .NET and JVM, there’s nothing preventing scripting languages from inherently supporting multiple dialects via compiled intermediary representations... But I digress... :)
      • shakna 7y ago
        Very few people write pre-ANSI C code today though, and the language itself was last updated in 2011. I'm sure people wouldn't gladly accept C code written for a 47-year-old compiler today.
        • bregma 7y ago
          > the language itself was last updated in 2011 The current standard languauge is C18.
        • jeygeethan 7y ago
          agreed!
      • simias 7y ago
        It's much easier for C to be backward compatible, not because it's a system language per se but rather because it's so minimalist. You don't have problems dealing with unicode when you don't deal with unicode. You don't have a problem dealing with ranges and iterators when your most advanced looping construct is for(i = 0; i < 10; i++). Other more advanced and fully-featured system languages like C++, Rust or Go have a different story to tell and making them backward compatible comes at a significant maintenance cost. Portability issues in C are mostly between architectures, not standard versions. The fact that "char" is normally signed on x86 but unsigned on ARM for instance is a common source of problems while porting code between these architectures. At least when you have python3 code you can be reasonably sure that it's going to run on any compliant python3 interpreter.
        • Mikhail_Edoshin 7y ago
          By the way, recently I realized that what I want is a language that does less instead of doing more. After all all these niceties with ranges and iterators are just syntactic sugar. Write pythonic code and face problems when porting this algorithm to C because C has nothing of Python niceties, which stop looking so nice at this point. Write non-pythonic C-like code without classes but with `__slots__` and functions all the way down and get not only the code that can be ported much easier to C and many other languages, but, surprisingly, also the code that is much more accessible and easier to reason about.
        • CJefferson 7y ago
          However, I can also still run C++98 code happily, and there has been no suggestion (AFAIK) from any major C++ compiler to remove this support.
      • syncsynchalt 7y ago
        I know you're writing tongue-in-cheek, but if you look at early C code you'll find it's not really supported today. The Lions book is full of "interesting" type magic, for example. However the best analogy for python 2to3 is probably the prototyping changes of ANSI C, and we similarly offloaded the conversion of that code to external tools (protoize(1) and unprotoize(1)).
    • tonyedgecombe 7y ago
      I wonder if they would have saved themselves five years of grief if they had done this five years ago.
      • theelous3 7y ago
        Likely the case. A lot of foot dragging took place. By five years ago most things of use were py3, conversion was easier than ever (and easy enough). More importantly, it would have stopped piles and piles of bleakly futured py2 codebases being written. That people were still writing new py2 code five years ago is terrible, and the long sunset is certainly greatly at fault here. That people are still writing new py2 code now is just criminal.
        • aketchum 7y ago
          the RHEL vm's that I get at my job (enterprise IT) have python2 installed by default and no python3. It is much simpler to write scripts in python 2 (albeit written in a way to support forward compatibility with 3) because python2 is just there by default on every VM and its one less requisition order to write. We are actually upgrading to python 3 at the end of this month, but we lived with python 2 for a full year. Just want to make the point that "writing new py2 code now is just criminal" is a tad overzealous.
          • theelous3 7y ago
            Well, it seems you were writing py3 code in py2, as much as was possible, so I wouldn't lump you in yo the criminal camp. Not everywhere had that foresight.
        • johnmaguire2013 7y ago
          I'm pretty sure Twisted(!) did not have Python 3 support 5 years ago. Also, macOS _still_ only ships with Py2. If I'm writing a quick script for my girlfriend to make her life easier, should I target Python 3 and force her to learn how to install xcode so she can learn to use homebrew so she can install Python 3, or should I just target Python 2 and move on?
    • deleted 7y ago
      [deleted]
  • mrweasel 7y ago
    I honestly don't believe that many will step up and take over. Many will complain, but few will do the actual work. Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.
    • leejo 7y ago
      > Many will complain, but few will do the actual work. That's opensource in a nutshell. If there are any big shops stuck on Python 2 then they will probably throw a resource or two at this. If there are big dists using Python 2 they will do the same.
      • Teknoman117 7y ago
        From what I can tell, even Google is moving to python 3 (some of their previously python 2 only tools (like repo) have gained ‘experimental’ python 3 support) this year, so they’re probably not going to be doing the work.
      • bigiain 7y ago
        > then they will probably throw a resource or two at this Which, I'd guess, is probably gonna be 3 or 4 orders of magnitude more money than they've ever spent supporting Python2 (or 3) devs in the 10+ years they've built their own businesses on it while they sat on their hands and ignored the project's urging to upgrade to Python3... Not a lot of sympathy from me for "big shops stuck on Python2"...
      • wyldfire 7y ago
        Canonical or Redhat will probably sell services related to supporting Python 2 and/or porting your code to Python 3.
    • richardwhiuk 7y ago
      Ubuntu 18.04 has support for Python 2.7 til 2028 I think.
  • kbumsik 7y ago
    I think the volunteers here refers the Python core developers and committers. In contrast to cooperation-backed popular modern languages like JS, Python team has few full-time devs maintaining Python. [1] Most of them literally are volunteers. [1] https://discuss.python.org/t/official-list-of-core-developers/924/6 https://discuss.python.org/t/official-list-of-core-developer...
  • antoinealb 7y ago
    > Not to mention paid FOSS developers at places like RedHat, who want to keep supporting their LTS and enterprise customers... Well RedHat annouced a long time ago that RHEL 8 will drop support for Python 2 [0], so at least it appears they also want to leave Python 2 behind. RHEL7 is already receiving security fixes only [1], which doesn't look like a huge "support" effort to me. Especially, behavior bugs and ports of Python 3 features to python 2 won't be done. [0] https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-No-Python-2 https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-N... [1] https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_1_Phase https://access.redhat.com/support/policy/updates/errata#Main...
    • em500 7y ago
      > RHEL7 is already receiving security fixes only [1], which doesn't look like a huge "support" effort to me. Nobody expects new features in python 2.7, so this is basically all the support that people are looking for. RHEL7 will have security maintenance till Jun 2024.
      • PeterisP 7y ago
        As we see from the python3 switch motivation, the key support people need is support for their favorite libraries. In that regard, maintenance for python 2.7 would involve backporting security fixes also for popular 2.7 third-party opensource libraries and frameworks even if those libraries themselves have already switched to python 3 only.
        • bigiain 7y ago
          I wonder how many 3rd party Python2 libraries RHEL ships with? I wonder if Redhat have left themselves enough weasel words in their contracts to say "Oh Python2? No security updates to the interpreter! Oh, you wanted explioted-library-de-jour updated? Well that's not covered in your support contract here. Left me put you through to our professional service division. Please have your contract ID and credit card number ready when they answer - transferring you now!" I'm 99.99% certain that if you ran "pip install numpy" on your RHEL7 box, and it's infected by a cryptominer the next day due to a know vulnerabilty, Redhat support are gonna laugh you off the phone when you call them up asking what they're gonna do about it...
  • goto11 7y ago
    Volunteers can of course step up, nothing is preventing anybody. But you shouldn't expect it will happen. Why would anybody voluntarily work on fixing bugs in obsolete software? People getting paid to work on Python (like at Red Hat) are not considered volunteers.
  • Scarblac 7y ago
    They did step up, even extended the time they were planning to step up by years, but it has to end somewhere.
  • deleted 7y ago
    [deleted]
  • squeaky-clean 7y ago
    They say volunteers, so I think they mean just people working for free. In the next section they mention you can probably find support from your vendors or pay a third party to fix it. It then ends with the sentence > If you need free help from volunteers, look at this help page. Which links to the help page to learn python, haha. I think the point is that you can fork it or pay someone to fork it, but you won't find anyone else willing to fix your problems for free.
  • MrStonedOne 7y ago
    Exactly! I am getting tired of FOSS orgs thinking they can speak for their entire extended community. `PSF` should be inserted before every occurance of the word volunteer in that page.
    • SiempreViernes 7y ago
      Uh, I think the PSF branding on that page is pretty clear. If you don't want to read a text in the context it's given that's your choice, but don't complain that it becomes ambiguous if read outside of its proper context.
    • bigiain 7y ago
      They're announcing that the (small group of) people developing the Python2 executable are no longer going to do so after Jan 1st. In what way does this imply that they're speaking for any "extended community"? Who're you trying to say is being mistaken here as being a "volunteer" but is not a 'PSF volunteer". I totally get that there is an "extended community" around the Python language(s), including at least module authors, people who write Python frameworks, and people who write code in Python - and _possibly_ including devs at companies who have built products in Python or relying on Python. But it's 100% obvious that the linked article is referring to none of those people. Who do you think this "FOSS org" was appropriately speaking for?
    • ajayyy 7y ago
      They manage merging though, so it has to be a fork.
  • falcolas 7y ago
    Not just RedHat - Google and Amazon have LTS that they're providing that will most likely include some flavor of 2.7. Google has flat-out stated that they will continue to support 2.7 in App Engine for an undefined period of time. Amazon has inferred through their Amazon Linux 2 LTS support page that Python 2.7 is included in that support for 3 more years.
    • floatingatoll 7y ago
      [resolved]
      • falcolas 7y ago
        Amazon; thanks. I got my threads crossed.
• wepower_ico 7y ago
  I still see companies working with Python2 but I am happy for this announcement - as it will make moving to Python 3 faster.
  • odiroot 7y ago
    Job security for us Pythonistas? Porting all this outdated code to Python 3.
    • truebosko 7y ago
      Totally. It's like getting a job in dated Java code bases. Tons of cruft to support. Boring work though
      • odiroot 7y ago
        Then automate. And still bill by the hour ;)
  • Scarblac 7y ago
    I don't believe this is a new announcement, the date has been known for years.
• Animats 7y ago
  Some shared hosting providers are still offering Python 2.6 as their main offering.[1] Optionally, there's Python 3.2, probably the worst 3.x version. [1] https://www.hostgator.com/help/article/what-software-and-program-versions-does-hostgator-offer https://www.hostgator.com/help/article/what-software-and-pro...
  • melling 7y ago
    I was Googling “HostGator Python 3” and found you said the same thing last year on HN: https://news.ycombinator.com/item?id=16808998 https://news.ycombinator.com/item?id=16808998 We knew in April 2014 that Python 2 was EOL in 2020.
    • Animats 7y ago
      Yes, I was hoping for some progress at HostGator so I could get rid of the last Python 2.x I have running. But I can't, yet.
  • toyg 7y ago
    PHP-style shared hosting is not where Python users are. The shared-hosting story for Python has always been pretty bad, with rare exceptions (webfaction, before godaddy swallowed it). Python users are overwhelmingly on VPS and PaaS, where versions can be easily upgraded. Any PaaS provider without Python 3.6+ at this point is not worth paying for.
  • markdown 7y ago
    > Shared hosting providers Like Google App Engine lol. GAE Standard Environment doesn't support Python 3.
    • jasoncartwright 7y ago
      This is incorrect. https://cloud.google.com/appengine/docs/standard/python3/ https://cloud.google.com/appengine/docs/standard/python3/
      • 7y ago
• leowoo91 7y ago
  It's always good to see such big movements but as a truly peaceful p2 dev, I'm not even considering to upgrade my projects unless it'd cost me labor not to upgrade.
  • WilliamEdward 7y ago
    I mean this announcement is not a threat, it's a warning. After a certain point there is diminishing returns on not upgrading.
  • rglullis 7y ago
    Given that you said "projects", why don't you try an experiment of porting one of the smaller projects and have and evaluate how much of a hassle it is? I am willing to bet you will figure out is not that complicated at all.
• j-pb 7y ago
  And now remind yourself that there are self driving cars out there and autonomous digging equipment that is based on ROS, which doesn't have any plan or intent to move to python 3. Fun stuff...
  • bootloop 7y ago
    Well the ROS wiki says otherwise: http://wiki.ros.org/UsingPython3 http://wiki.ros.org/UsingPython3
    • j-pb 7y ago
      Yeah but the general consensus for the core stuff seems to be "we'll do that with 2.0", which at this point seems to materialize since forever aka. vaporware...
  • carlmr 7y ago
    Is ROS used in production for this? I've only seen it used for prototyping.
    • j-pb 7y ago
      Yeah, Built Robotics[1] apparently does, at least according to their hiring page. And I think Audi is using it for their self driving cars... https://www.builtrobotics.com/ https://www.builtrobotics.com/
      • carlmr 7y ago
        I mean hiring page doesn't mean they actually use it in the product. You can use ROS for designing the system, but in terms of performance it has issues if you try to use it in an embedded context. I still kind of doubt they have it running in their product.
        • j-pb 7y ago
          Makeshift solutions last the longest, I'd highly doubt that they run 2 messaging systems side by side, thats just unrealistic for a startup. Especially considering that ROS is very invasive with it's MSG format and build tooling.
• sharperguy 7y ago
  Maybe now the Android AOSP build scripts will be updated to python3....
• gigatexal 7y ago
  The transition to python 3 from 2 was rough I’ll give you that. But companies and maintainers have had years and years to either fork and port or altogether rewrite their code for python 3 — the only python that matters. I liked the stance the post took: it was very matter-of-fact in its tone regarding python 2 support — consultants are there for that and they will charge a mint to give you time you should have taken to move your codebase to python 3.
  • mk89 7y ago
    From my experience, large codebase refactorings are almost never a priority until the deadline is just right there. 10 years for many companies mean the last 6 months, when everyone else has already done a lot of work on the same problems as you will encounter, lots of issues have been already solved, and you can probably find people with the python 3 skill. And last but not least, you will find approvals from management side "this year's the end of support, it must be done, otherwise we are out of security patches". So, essentially yes, they gave a lot of time for enterprise companies to let others do the dirty work :)
    • ilikehurdles 7y ago
      That's true. I worked at an enterprisey shop that delayed upgrading from Java 6 before its EOL. By the time they started, the EOL date had passed a few months prior and the upgrade itself was a 1.5 year effort. Some orgs can be pushed, others have to be shoved.
• cm2187 7y ago
  So they are sun-setting it 12 years after having introduced its replacement. I think there is a parallel with the .net Framework. .Net core is a similar breaking change (not the syntax of the language but very much so in term of core libraries and project types). I wouldn't be surprised if .Net full followed a similar timeline.
  • hit8run 7y ago
    .Net 5 will be reuniting the brands (Though based on .net core). So the Core brand will be discontinued. Read more about it here: https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/ https://devblogs.microsoft.com/dotnet/net-core-is-the-future...
    • cm2187 7y ago
      The brand is one thing but your project will still be incompatible.
    • leadingthenet 7y ago
      They're changing the branding ... AGAIN?!
• jedberg 7y ago
  In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet. In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now. For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backing it up.
  • spurdoman77 7y ago
    Personal use can be quite different to business use cases. For many companies the conversion can be quite horrific, they might be quite happy to pay for support for older versions.
    • jedberg 7y ago
      I meant my personal business use case.
    • senko 7y ago
      There are companies offering extended support beyond EOL for version 2.
  • reitzensteinm 7y ago
    Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short. Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.
    • PeterisP 7y ago
      The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now". If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.
• brnt 7y ago
  Every now and then a language like no other pops up: it's use is unusual and unusually long. Various biblical languages come to mind: Latin, Church Slavonic, Hebrew at one point. These languages are feature complete, and the fact that they didn't change was their main appeal. I've always thought Python 2 might be headed for the languages. Which is fine, it's great to have a programming equivalent of Latin.
  • onethought 7y ago
    ... I'm sorry, but wouldn't the Latin equivalent be C... given Python is written in it, and most languages syntax is born from it. Python is more like the English language... it's borrowed a bunch of stuff from many different languages and isn't even compatible with itself ;) (2 vs 3). I mean, this is assuming with thing spoken languages are even at all similar to programming languages... which I don't think they are.
    • brnt 7y ago
      C is a great example of a Latin too, agreed. There can be multiple ;)
  • jedberg 7y ago
    Latin is getting new words all the time. The Vatican is the official maintainer. Sometimes it gets grammar tweaks too. Hebrew was completely replaced with modern Hebrew and gets new changes constantly.
    • brnt 7y ago
      I guess I didn't go deep enough with the analogy. Python 2 sees new code all the time too. It's not dead! That's the whole point, it can simultaneously not see any new changes but still be used by those who value the absence of change.
    • edanm 7y ago
      > Hebrew was completely replaced with modern Hebrew and gets new changes constantly. Just to clarify further, modern Hebrew is mostly backwards compatible with biblical Hebrew, it's not an entirely new language. It was mostly updated in terms of vocabulary that was necessary for the modern era, plus some spelling/grammar changes. Modern Hebrew speakers are able to read biblical Hebrew almost completely, though there are some differences (think of English speakers reading Shakespeare - though even less difference than that.)
• tams 7y ago
  With the sunset date passing, Python 2 is going to become a niche while still having a massive install base. There's a lot of money to be made doing migrations and keeping the beast itself alive.
  • carapace 7y ago
    Yeah, that's my career for the next ~20 years... I'm not complaining. I like Python 2.
• johnlinvc 7y ago
  The battle has not over yet. RHEL 8 has Python 2.7 in their Application Streams. So looks like Red Hat will provide security updates until Jun 2024 https://access.redhat.com/node/4079021 https://access.redhat.com/node/4079021
  • jabl 7y ago
    There was some mention somewhere that RH will support the python 2.7 appstream for RHEL 8 as long as RHEL 7.x is supported. Which coincidentally is June 2024, so, yeah.
• choppaface 7y ago
  "What will happen if I do not upgrade by January 1st, 2020?" "You will lose chances to use good tools because they will only run on Python 3, you will slow down people who depend on you and work with you." The tone in this document is excessive and over-the-top. If the author spent half the document demonstrating (with examples) why Python3 is so great, it might actually be useful and get people upgrading like right now as they're reading it. But instead, it seems the author simply wanted to convey how sick they are of Python 2. The author does not appear to understand their users; that's their real frustration. In life outside of Python... The transition in C/C++ from C++98 to C++11 and then C++20 (and beyond) has been quite clean and professional. There were some glaring issues with C++11 that later got patched up (e.g. rvalues but no optional, no filesystem, make_unique, etc). Most importantly, compiler support and standard distributions improved a lot. There were often clear incentives to upgrade, and it was relatively easy to stick to an old standard where necessary. In contrast, Python has become a bit fractured, with a number of notable well-discussed but unaddressed loose ends in Python3: http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in... I think the Python community has failed to present strong enough incentives for upgrading to Python3, and that's why users are sticking to Python2 and 'slowing everybody down'. The jump to C++11 was obviously needed: at the very least, `auto` saved much of your sanity and you no longer really needed to include Boost in your build. But you could stick to an old standard if you wanted; you could even transition a codebase module-by-module in some cases. The Python3 community seems to have been groping for a similar killer feature (e.g asyncio, as discussed in Amber Brown's talk above), but the value-add isn't so clear. `six` is honestly a nice catalogue showing how many changes in Python3 are largely sentimental. Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.
  • shakna 7y ago
    > The tone in this document is excessive and over-the-top. If the author spent half the document demonstrating (with examples) why Python3 is so great, it might actually be useful and get people upgrading like right now as they're reading it. If people haven't found reason in the last ten years, then they aren't about to be convinced today. All the arguments for and against have already been widely discussed, and that the EOL of Python2 is here should come as a shock to exactly no one. There's no reason to re-hash over and over what is already out there.
• sireat 7y ago
  The otherwise amazing Windows service ninite.com is still offering Python 2.7.16 and is not offering Python 3. There was a discussion on HN about this a few years ago, but I am curious to see what does ninite.com plan to do now?
• EnderMB 7y ago
  While the article is very "matter-of-fact" about the sunset period and what it means to those that still use Python 2, I'm still surprised that it's taken this long to finally close support. I had assumed that their approach would be to fork the language into a new language (call it something like Liasis) and to allow one of the big-name contractors that specialise on Python 2 to take ownership of it. As an aside, a few weeks ago I interviewed at one of the top 5 investment banks for a software engineering role to maintain one of their main trading systems, written entirely in Python 2. My first question was what their plans were in porting what they called "one of the worlds largest Python 2 code bases," and it was "on the roadmap". Surely the Python core team are aware that teams like this exist in some of the largest companies in the world, and I assume they've had at least some level of dialogue with companies like this to say "we're super serious this time, we're about to stop support for Python 2", or something along those lines? Maybe it's a blessing in disguise that I was rejected?
  • Scarblac 7y ago
    Well, the largest companies in the world don't have to rely on volunteers, they can pay for continued support.
    • EnderMB 7y ago
      I've never worked for a company of that scale, so I don't know how hard it'll be to find legacy developers, but I imagine it'll take at least several years to port a public-facing system to Python 3, if they were to start now. If they start in the next few years, I imagine it'll be much harder to find ready and willing Python 2 developers with the experience to navigate such a big code-base? They could hire consultants, but I imagine the future hiring cost will also be astronomical.
      • Scarblac 7y ago
        Well Python 3 came out in 2008, this date is known since 2014. If they start in the next few years, yes you'd expect it to be expensive. But distribution vendors like Red Hat and Ubuntu have Python 2 in long term support distributions that they will give support for a few more years, so it is possible to use those. And after that they offer more years of support to paying customers. It's not necessary to hire programmers to do this for the companies needing support themselves.
• voldacar 7y ago
  I long for the day when typing "python" into a shell will bring up a python 3 prompt
  • avian 7y ago
    Switch to Arch Linux and live the dream. It has had python3 as /usr/bin/python since 2010. https://www.archlinux.org/news/python-is-now-python-3/ https://www.archlinux.org/news/python-is-now-python-3/
    • ImaCake 7y ago
      My mint 19.2 installation does the same. To run a python 2 script I have to run my conda python 2.7 install now.
    • Lendal 7y ago
      Is Manjaro included in that? Edit: Yes Manjaro has default Python3 too. :)
    • shpx 7y ago
      Also Gentoo since mid-2018. Although their package management requires manually specifying the minimum accepted Python version for every single package, so they have thousands of packages that would run just fine on Python 3.7 but no one has the time to manually check and label them as such. So their default is still 3.6 and using 3.7 as your default version is not well supported. I wish someone told me Gentoo is a non-starter before I wasted an afternoon installing it. While we're on the topic, it's pretty stupid how PEP 394, the one that says "python should point to python2.7", gives its reasoning as "because all Linux distros except Arch do it this way" and then all the distros say "python should be python2 because the PEP says so" for the next 9 (maybe more) years. How is anything ever supposed to change?
  • sametmax 7y ago
    Windows 10 now offer you to install Python 3 if you do this.
  • alerighi 7y ago
• _pmf_ 7y ago
  Is it really necessary to take over the euphemistic newspeak of Google?
• stefantalpalaru 7y ago
  We are volunteers who make and take care of a Python2 fork with backwards-compatible Python3 features. That means we will keep on improving it without breaking your code base or forcing you to hire the language creator and spend more than 3 years porting your code to Python3, with no actual business benefits. https://github.com/naftaliharris/tauthon/ https://github.com/naftaliharris/tauthon/
• m0zg 7y ago
  Meanwhile, TensorFlow build _still_ defaults to Python2. :-)
  • xenator 7y ago
    May be I didn’t noticed it. Pretty comfortable use it on python3 in my environment. So, from my point of view, authors of the TensorFlow just need to update documentation to complete transition.
• d--b 7y ago
  Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a long time. Since the stuff is open source, wouldn't it be nicer if it was possible to fix a bug if needed? Not saying that it should be actively worked on. But maybe one person could be appointed to look over bug fix pull requests (which shouldn't be that frequent these days).
  • VBprogrammer 7y ago
    As someone who works on a 99% Python 2 codebase I think this is a very necessary step. Hopefully one of our larger customers will realise we are still running their critical infrastructure on Python 2 and make enough of a fuss that we can justify the expense.
    • melling 7y ago
      It was announced in 2014 that support was ending in 2020. It seems a bit wrong to surprise a customer now.
      • VBprogrammer 7y ago
        We have a more complicated relationship with our customers than that implied. Suffice to say they wouldn't actually be footing the bill.
    • liveoneggs 7y ago
      even if you do the same thing will happen with python 4; these languages are not built with long term stability in mind
  • unionpivo 7y ago
    thats the worst kind of limbo, sort of supported and official but not really. I fully support them in this. Either you support it right, or you abandon/sunset it clearly. If someone else wants to step up and do the work, they can always do that on their own.
    • 7y ago
• kuu 7y ago
  I don't think the main problem is to change the version of Python, but the version of all the related libraries, which many of them depend on 2.7 version. I know many of the big ones are already on 3.x for a long time, but I wonder how long will it take to replace and upgrade all the small ones if it did not happen already... BTW I don't know how necessary was to break compatibility between 2.7 and 3, the pain of this transition comes from that decision
  • rlayton2 7y ago
    Any major library that hasn't moved to Python 3 by now isn't going to on their own accord. Either that means they won't, or that the sunsetting will kick them into gear (or get their users to kick them into gear). It should be pointed out that Python 2 will continue to be used, and be usable. It just won't get new security upgrades or features. I do not know, but I doubt if there will be a feature or security flaw come up soon that "forces" existing python 2-only libraries to update
• tobr 7y ago
  I don't have a stake in this and don't know much about the background, so pardon if this comment is out of touch. Is this the first notice of this date? January 1 is just 16 weeks away, which seems like an awfully short notice for ending security updates of a very popular language. EDIT: I see now that they mention that 2020 has been the plan since 2014, which seems reasonable.
  • melling 7y ago
    Nah, we got a 5 year extension about 5 years ago: https://news.ycombinator.com/item?id=7581434 https://news.ycombinator.com/item?id=7581434 https://news.ycombinator.com/item?id=7372913 https://news.ycombinator.com/item?id=7372913
  • raverbashing 7y ago
    If you read the article it was explained there, but tl;dr: it was announced in 2014 (that support would end in Jan 1st 2020)
    • rndgermandude 7y ago
      It was announced in 2014 that the sunset day would be further extended to 2020. The original sunset date was 2015, announced in 2008. That's more than 10 years ago that the intention to sunset python2 at a specific date was announced. Anybody who, after 2008, started new, serious python2 projects that were supposed to have a life expectancy beyond a few years was rather "optimistic", and anybody who did after 2015 was almost callous, especially if you "played" with other people's money.
• CJefferson 7y ago
  One missing question: Q) I like Python 2. Can I take over Python 2 maintenence? A) NO. Try it and we'll sue you.
  • WilliamEdward 7y ago
    Why would anyone like python2 so much better than python3 that they would want to fork it into its own language? The two languages are already incredibly similar and python3 has a much larger active community.
    • alexmlamb 7y ago
      It's having to write the parenthesis after print. No one wants that and it's been by far the largest complaint the community has about python3.
      • lutoma 7y ago
        > No one wants that Why would you write a statement that is so demonstrably false?
        • mehrdadn 7y ago
          Probably because it's hyperbole to get a point across.
          • jiffyjeff 7y ago
            I don't know if the author was intending to be hyperbolic -- I for one prefer Python 2's print. I would've preferred keeping print the way it was and using a new keyword for the new functionality.
            • aequitas 7y ago
              The change in the print statement was also what put me off from Python 3 for a long while. But back then there where also no big benefits to be had from moving to 3. Nowadays I even prefer the print function as it makes it easer to convert to log functions.
• adamhepner 7y ago
  Great stuff. But what about alternative python interpreters that have been lagging behind? Jython is 2.7.1 and IronPython is 2.7.9
  • robin_reala 7y ago
    IronPython is a dead project at this point…
    • DonHopkins 7y ago
      Well, he's... he's, ah... probably pining for the fjords.
  • icebraining 7y ago
    For the JVM, there has been some work on new interpreters for Python 3 based on GraalVM. Unfortunately none seem production-ready at the moment.
  • toyg 7y ago
    They are effectively both dead or moribund. Jython has had a py3 experimental branch for ages but the entire project is basically starved of money and effort. To be honest, the whole “Python on other runtimes” movement, as a concept, is more or less over. It’s just too much effort for too little reward, now that CPython has good libraries for pretty much anything you can think of.
    • sjwright 7y ago
      Does that view include PyPy? I'm not deep into Python (aside from the Monty kind) but it seems to be maintained and makes performance claims.
      • toyg 7y ago
        PyPy is a python-focused project that builds a python-focused runtime. My comment was more about projects trying to retrofit Python on top of runtimes that were built for very different languages, typically because of some constraint that has now disappeared.
• anilakar 7y ago
  I wish Python Software Foundation had worded their announcement differently – in the SW development context, even a plain "support for this version ends on dd.mm.yyyy" sounds more professional and friendly than the word "sunsetting" that has just too many negative connotations nowadays. From past experience it usually means that a startup is pulling the plug or has outright gone bankrupt.
  • Tom4hawk 7y ago
    I think you are in a startup echo chamber/bubble. Most of the world doesn't have any negative connotations with that word. You cannot cater to everyone...
• chirau 7y ago
  Honestly speaking this EOL was made clear almost 6 years ago. If you are still on 2 you are probably best left to your own devices. 6 years is way way more than enough time
  • intea 7y ago
    >in 2008, we announced that we would sunset Python 2 in 2015 More like 12 years by now :-)
• sweettea 7y ago
  Sad to see them forging ahead on their plans to drop Python 2, and it would have been nice of them to point out that other volunteers will provide security fixes for Python 2 compatible runtimes. I've switched to Tauthon [1] for over a year now and have been quite pleased. Consider the switch yourself rather than rewriting your code. [1] https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon
  • jedimastert 7y ago
    In your opinion, is there any particular reason to start a new project, or is this disappointment for lack of legacy support?
• thefabsta 7y ago
  A popular library that has unfortunately not transitioned to Python 3 yet is rospy (which is part of the larger ROS ecosystem for robotics). It is the last framework that prevents me to fully embrace Python 3 for my everyday work. I sincerely hope the robotics community will eventually port rospy (and other ROS-related libraries) to Python 3. I am, however, very happy to see that ROS2 (the next iteration of ROS) uses Python 3 by default.
  • sickcodebruh 7y ago
    I'm in the same boat. It bothers me that my only option will be to rewrite in Python 3. Unless they provide a very clear migration path, I'm far more likely to just remove ROS entirely, unfortunately.
• Stay_frostJebel 7y ago
  Kill it with fire! Should have been removed years ago. It actually causes real issues, such as build systems that only support python2 but not python3. The sooner python2 dies, the better. I need to use both python2 and python3 since otherwise quite several software projects refuse to compile from source. An example is Mozilla's mozjs. http://www.linuxfromscratch.org/blfs/view/svn/general/js60.html http://www.linuxfromscratch.org/blfs/view/svn/general/js60.h... Also increases your trust in the company creating Rust when they are too lazy to fix their whole build suite. Total clowns working at Mozilla here.
  • jsjohnst 7y ago
    > Total clowns working at Mozilla here. Was the cheap shot really necessary?
  • steveklabnik 7y ago
    > Also increases your trust in the company creating Rust when they are too lazy to fix their whole build suite. Mozilla is not in charge of Rust in any way.
  • hjkl2 7y ago
    It is a work in progress: https://ahal.ca/blog/2019/python-3-at-mozilla/ https://ahal.ca/blog/2019/python-3-at-mozilla/
• drej 7y ago
  What surprises me about this is that the documentation for Python 2 does not explicitly say that the language version is about to be unsupported, see e.g. https://docs.python.org/2/library/zipfile.html https://docs.python.org/2/library/zipfile.html Contrast this with the Postgres website, which tells me I'm browsing old docs (because Google still offers old links), see e.g. https://www.postgresql.org/docs/9.2/tutorial-window.html https://www.postgresql.org/docs/9.2/tutorial-window.html Are there plans to add a banner to Python 2's docs? I think it would be quite instructive.
  • pelario 7y ago
    I cannot agree enough. As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.
    • lonelappde 7y ago
      This issue is part of why Haskell is so hard to learn. Haskell's package database Hackage keeps all old deprecated incompatible versions of packages, with documentation pages all well indexed by Google, with higher page rank because they are longer lived than the current package version, with no indication that they are deprecated and incompatible with current Haskell deployments.
      • marcosdumay 7y ago
        Try Hoogle.
        • moomin 7y ago
          Hoogle has its own problems...
      • madsbuch 7y ago
        This is also the problem haskell stack solves
• jwr 7y ago
  When people mock me for writing long-term projects in Perl 5 (https://github.com/jwr/ccheck https://github.com/jwr/ccheck), I point them to the Python2/3 change. From an outsider's point of view, this change was not coordinated well and the timeline is too short. To clarify: long-term means automotive time scales: I want to be able to run my software in 10 years.
  • capitol_ 7y ago
    If 12 years is too short, how long timescale do you need? Python 2's EOL was first announced in 2008.
    • dannyw 7y ago
      Python 2 was nowhere near ready for EOL in 2008; making it not very credible.
    • slightwinder 7y ago
      For the first 8-10 Years, migration was not possible for most people for several reasons, shrinking the timescale to 2-3 years for the majority.
      • mixmastamyk 7y ago
        Though you could have done most of the work ahead of time.
    • CJefferson 7y ago
      To be honest, never. I work on a C program that's about 30 years old. We've slowly moved, at our own pace, to C99, then added some C++ here and there. I don't ever want to have a forceful change, where I have to go and edit code which has worked correctly for over 15 years, just to make a compiler happy.
      • tcd 7y ago
        Yeah, sorry buddy, but that's just not how modern software dev works. Platforms change, code gets outdated, and whilst older platforms "work", they're likely not taking advantage of all the features that have been added to platforms since that time. It's much easier/better when you are forced into dealing with the change. At least people can laugh at how annoyed others get when they cry "but you broke everything!". It's called progress. Get with the times or get outdated.
• lbj 7y ago
  Finally.
• acollins1331 7y ago
  Thank God. It's been really annoying having to add parenthesis to all the print statements when I accidently download a python 2 script.
  • iwalton3 7y ago
    I've found that the 2to3 script will do this. The real pain is finding everything that now has to be bytes instead of string.
    • someguydave 7y ago
      which is why python3 is dead to me.
• charlus 7y ago
  Given we'll be at Python 3.8 next month, I can't help but wonder about Python 4. When it will happen, and how long.
  • WilliamEdward 7y ago
    I dont think python 4 will be what you think it will. Most likely it will just be the next version of 3, not a game changing upgrade.
  • coleifer 7y ago
    New features planned for python 4.0: http://charlesleifer.com/blog/new-features-planned-for-python-4-0/ http://charlesleifer.com/blog/new-features-planned-for-pytho...
    • toyg 7y ago
      You missed a /s there.
  • toyg 7y ago
    All indications are that we'll see 3.10 before 4 is considered. I think it would probably be ok to start thinking about it in a year or two from the py2 sunset. It will be a minor update anyway, it's just a PR exercise that can be done whenever people think it would be more effective.
• aaron695 7y ago
  Is there a list of Open Source that needs converting? The first obvious one to me to check found this - > Bug Description Python 2 is retiring in thirty months. Calibre needs to convert to Python 3. > No, it doesn't. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase. https://bugs.launchpad.net/calibre/+bug/1714107 https://bugs.launchpad.net/calibre/+bug/1714107
• starpilot 7y ago
  rising
• ken 7y ago
  Python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done. There's a library ("six") to help, and in almost all cases you can write 2-and-3 compatible code, which means you can go piece-by-piece. (Unless your manager makes drive-by commits of py2-only code, months after you all agreed that all new code should be py3-compatible, and then leaves town for a multi-week vacation...) Dependencies? I helped upgrade a couple third-party modules, too. That's part of the job. If you choose to use a dependency, you're vouching for it. That means if the current version of the language no longer supports your favorite library, you need to fix the library, or find a new one. If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago. Apple took only 3 years to go from first announcing a new CPU architecture to releasing an x86-only OS. 2 years later, Rosetta stopped working, so there was no way to run old apps on current hardware at all. That's got to be one of the advantages of proprietary systems. It's amazing what you can accomplish when you have no choice. People complained a little but they got it done.
  • sdoering 7y ago
    > If we switched from phillips to torx, and your favorite tool brand didn't make torx drivers yet, you've got to either convince them to start, or switch brands. This is the best analogy I have yet read. Thanks - you nailed an argument I have had at multiple gigs/clients way to often. > Professionals don't get to use this as an excuse to badmouth torx, and stick with phillips. D'accord. Exactly. I had very fruitful discussions with professional builders about tools, tool brands and their respective strengths and weaknesses - but never has a professional decried Bosch Pro vs Makita vs DeWalt. One has ones favorites - and that is fine. But badmouthing - I have never encountered.
    • deleted 7y ago
      [deleted]
    • kortilla 7y ago
• jshowa3 7y ago
  Honestly it's about time. I've been annoyed at having to maintain two versions of python.
• rough-sea 7y ago
  Is there even a plan to transition the chromium code base to python3?
  • rough-sea 7y ago
    This issue is marked as wont-fix https://bugs.chromium.org/p/chromium/issues/detail?id=61357 https://bugs.chromium.org/p/chromium/issues/detail?id=61357 Here is another issue which looks more recent and hopeful https://bugs.chromium.org/p/chromium/issues/detail?id=942720 https://bugs.chromium.org/p/chromium/issues/detail?id=942720
• perfunctory 7y ago
  People spend more time whining about the transition than it would take to do the actual transition. Sigh.
• tibbon 7y ago
  One thing that confuses me about Python is just how many projects don't specify if the app is supposed to use 2 or 3, and the correct answer isn't 'either'. Check out something from Github, only to find I actually do need Python 2.7 or something. Is it that Python developers assume everyone will just intuit the version, or is there a default?
  • StavrosK 7y ago
    It's usually specified in setup.py.
  • toyg 7y ago
    Rule of thumb is that no version == python2, either because it pre-dates 3 or because the developer's concept of python is "what happens when I type python at the shell" so it's still 2. It's often a big red flag about quality; competent Python developers find it natural to state py3 support upfront (or lack thereof) because they know it matters.
    • ssully 7y ago
      I think your point about competency is the best point. Recently though, I have been running into more and more projects that don't specify the version and are built using Python 3. I also used your rule of thumb, so seeing this was kind of surprising. Wonder if it's just the mentality shift that Python3 == Default?
    • BeetleB 7y ago
      Eh. Disagree. For small projects on Github that are actively maintained, it's more likely to be Python 3 and not Python 2 if not explicitly stated. Newer developers for newer projects just don't care about Python 2.
  • reilly3000 7y ago
    If not otherwise specified, I just look for a `print` command and see if its formatted as print 'my string' indicating Python 2 or print('my string') indicating Python 3.
• CriticalCathed 7y ago
  Time for python 4. Python 3 to sunset in 2025!
• arendtio 7y ago
  Does someone know if there is a way to compile python programs to some sort of static binary? I have a GPS watch and some old Python 2 script to export the data (found it online (unmaintained) a few years ago). However, when Python 2 will be sunsetted I am a bit worried that Linux distributions will stop packaging the dependencies of said script, but I would like to keep using it until the watch breaks.
  • xd1936 7y ago
    You could give py2exe a try. They have an old python2 version that might work for you. https://sourceforge.net/projects/py2exe/files/py2exe/0.6.9/ https://sourceforge.net/projects/py2exe/files/py2exe/0.6.9/
    • arendtio 7y ago
      Thanks, sounds like what I am looking for, but sadly it doesn't seem to be available for Linux :-/
  • BeefySwain 7y ago
    Docker could do what you want, though it's definitely not an efficient solution.
    • arendtio 7y ago
      Nice idea. Might be a good start to learn to build my own docker images.
  • throwawaymlc 7y ago
    Which script are you talking about? Can you send me a link to it or or something? Email is in my profile. I would be interested to see if I can update to python 3.
• crb002 7y ago
  Guessing some Python 2 users rebel and fork to provide security patches.
• antoineMoPa 7y ago
  This should have been done in 2010. People will procrastinate 12 years if you give them a 12 years deadline.
• ssully 7y ago
  On the topic of large companies still using Python 2, I would love to hear about Splunk's upgrade plans. They have the following[1] on their SDK page about upgrading, but my understanding is their entire platform is still on Python 2. I've upgraded a number of projects at my work to Python 3 this year, but nothing that 2-3 developers couldn't do in a few weeks. Can only imagine the headache of migrating something the size of Splunk. [1]: https://dev.splunk.com/view/SP-CAAAFG7 https://dev.splunk.com/view/SP-CAAAFG7
  • metasyn 7y ago
    Granted I don't work at Splunk anymore, but did recently. They were definitely working hard on migrating everything to python3, and if I remember, they had a planned roll out where python2/python3 would co-exist. However, if you've been using the python SDK for Splunk - its been supporting python3 for a few years already (https://github.com/splunk/splunk-sdk-python/commit/4503db9611d1475e9d49f69bd689540f5717e95f https://github.com/splunk/splunk-sdk-python/commit/4503db961...) See this blog post: https://www.splunk.com/blog/2019/07/01/admins-and-developers-we-re-transitioning-to-python-3.html https://www.splunk.com/blog/2019/07/01/admins-and-developers... And this helpful doc: https://docs.splunk.com/Documentation/Splunk/7.3.1/Python3Migration/AboutMigration https://docs.splunk.com/Documentation/Splunk/7.3.1/Python3Mi...
    • ssully 7y ago
      Really appreciate those links! I honestly had no idea the SDK has supported Python 3 for this long. Granted, I haven't worked with it since 2015, but still surprised I missed that. Glad to hear they are making such good progress.
  • TransAMrit 7y ago
    I work at Splunk - we're in the process of upgrading to Python 3 support. It's about as much of a nightmare as you would expect with a 15 year old codebase with [essentially] plugin support (by way of external Python code in Apps). The good news is, we've entered Beta!
• carlmcqueen 7y ago
  This is good news for new users to python when getting books that start with an argument for using 2 or 3 and then the book trying to be in both.
• salamanderman 7y ago
  My new Mac laptop in 2016 came installed with Python 2.7 from Apple. It's that kind of subtle defaults that I think slowed the transition. I didn't want to change the system Python.
  • pudquick 7y ago
    In 2016, that laptop also came with System Integrity Protection - you couldn't change /usr/bin/python if you wanted to. And you still can't to this very day. Changing System-provided python was always against recommendations in prior OS versions because the next OS update could re-replace it at any time. I agree that it probably contributed to python 2 inertia as it was re-exposing people to the idea that "typing python in the Terminal gets me python 2" and "I just used what I already had" - but it definitely wasn't stopping people installing a newer version.
    • CDSlice 7y ago
      Actually you _can_ disable SIP and replace use/bin/Python, but that is a Very Bad Idea.
  • PhantomGremlin 7y ago
    Apple will (eventually) entirely remove Python: https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_beta_7_release_notes https://developer.apple.com/documentation/macos_release_note... Hopefully they will fix the shitty keyboard before that happens, so I can finally replace my old Macbook Pro. Scripting Language Runtimes Deprecations Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202) Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7.
• nickjj 7y ago
  I'm happy this finally happened, even though I've been clinging to Python 2.7 for quite some time. I run a Flask course[0] and from the beginning I coded the app to work for both 2.7.x and 3.x in parallel but it's only been a few months now where Celery supported Python 3.7. In either case, upgrading from 2.7.x to 3.7.x was super painless. It came down to making sure Celery is using 4.3+ and pytest requires 5+ if you plan to use Python 3.5+. There wasn't any app level changes that had to be done other than optionally removing some dual import try/excepts to work for both 2.x and 3.x. The biggest pain point was remembering to use print with parenthesis but I've been doing that for a while now so it's a non-issue. This was based on a decently sized Flask app with tens of top level dependencies and many thousands of lines of code. If someone wants to see how this upgrade process looked in real time, I recorded that and put it up on Youtube[1] the other week. The video also covers some gotchas you might encounter during the upgrade process (especially if you're running in production and deal with sessions). [0]: https://buildasaasappwithflask.com/ https://buildasaasappwithflask.com/ [1]: https://nickjanetakis.com/blog/upgrading-a-dockerized-flask-app-from-python-2-7-to-python-3-7 https://nickjanetakis.com/blog/upgrading-a-dockerized-flask-...
  • guitarbill 7y ago
    pytest has has python 3.5+ support for a while, even 4.0.0 supported it: https://pypi.org/project/pytest/4.0.0/ https://pypi.org/project/pytest/4.0.0/ . although the recent pytest changes are well worth picking up!
    • nickjj 7y ago
      > pytest has has python 3.5+ support for a while, even 4.0.0 supported it: https://pypi.org/project/pytest/4.0.0/ https://pypi.org/project/pytest/4.0.0/ . although the recent pytest changes are well worth picking up! Yes but check the changelog for pytest. Version 5.x.x is only available for Python 3.5+. They dropped support for 2.7 and <= 3.4, unless you fall back to the 4.6 series.
• mistrial9 7y ago
  > We need to sunset Python 2 so we can help Python users. We need to <specific goal> so we can <universal statement>. That statement is boilerplate manipulative garbage.. its ok to speak this way because you agree with the goal ?
  • rco8786 7y ago
    It’s certainly a meaningless statement, but I don’t think it’s manipulating anyone
• Siecje 7y ago
  I'm curious which PyPI packages are preventing you from updating to Python3?
• Pxtl 7y ago
  11 years to make relatively small breaking changes. That's not a good sign for future breaking changes.
• coliveira 7y ago
  That's why Python receives a bad name, and for a good reason. Nobody is telling people who use Java since version 1 that they need to upgrade code if they want to continue using the language. The code just works, and will continue to work as long as there are compilers for Java. The same thing about C and C++, these languages introduce new features as times evolve, but they still allow users to retain their investment in old code. This is not the case with Python. Because of some bad design decisions, they inflicted pain on their users for more than a decade to force them into choosing one version or another. And now they are deprecating a version of the language that is still used by millions of people, causing again more trouble. Why in the world they need to deprecate this code when there are millions of people who use it all day long? I still see lots of code continuing to be written in Python 2, and all this code will have to be rewritten just because of some bad design and implementation decisions of a few people developing this language.
  • Lt_Riza_Hawkeye 7y ago
    >Nobody is telling people who use Java since version 1 that they need to upgrade code if they want to continue using the language. The code just works, and will continue to work as long as there are compilers for Java This is the same with Python. Python 2 code will continue to work with python 2 interpreters, just as java 1 code will continue to work with java 1 JVMs and JDKs. But neither are being actively developed and Oracle will not even sell support for java 1, let alone release security updates.
    • Yhippa 7y ago
      I'm on the outside looking in but practically speaking, why couldn't I "just use Python 3" then for everything?
      • gvb 7y ago
        Python 2 and 3 are different compiler/interpreters. Python 2 code might run on a Python 3 interpreter, but probably not. When you run your python2 code, you can specify that it is to run on the Python 2 compiler/interpreter. The Python 2 compiler/interpreter will continue to run and thus be able to run python2 code for a very long time. Ubuntu 18.04 example: $ python --version Python 2.7.15+ $ python2 --version Python 2.7.15+ $ python3 --version Python 3.6.8 $ ls -l /usr/bin/python lrwxrwxrwx 1 root root 9 Apr 16 2018 /usr/bin/python -> python2.7
• rolltiide 7y ago
  Python Two distinct languages that happen to have the same name
• mwkaufma 7y ago
  I would have loved to upgrade sooner, but I work in technical art and all our tools are version-locked by native python extensions and QT5's compat. See discussion at: https://vfxplatform.com/ https://vfxplatform.com/ I predict Maya devs (and, by extension, game engine vendors. like Epic/Unreal, who version-lock to Maya's version) will stay on 2x well past 2020 by making their own platform-compat patches.
• eruditely 7y ago
  It seems everyday that history moves on, anyways this is a historic day and I applaud the principal's for making a difficult decision. I wish them all the best. I've only used python for scripts and such and pandas for data-analysis at my last job.
• dangxiaopin 7y ago
  I think the sunsetting is very premature. Python 3 became a stable and viable alternative only since 3.6.1 (look at the evolution of async/await before that for example). Giving it 2 years is definitely not enough for enterprise (unless their focus is startup, tinkerers and data scientists)
  • pudquick 7y ago
    That being said - python 3 was released in 2008. A 12 year transition is pretty respectable.
  • AlphaSite 7y ago
    I mean, arguably they’ve been telling you too move for far longer. So it seems reasonable to sunset it after 10 years.
    • dangxiaopin 7y ago
      So migrate a large production codebase to unstable API? With dependencies not yet migrated?
      • partialrecall 7y ago
        Loads of open source and commercial projects have already made the switch to python 3 years ago. If all of them could do it, so could your org. No excuses, you've made your bed, etc.
      • mixmastamyk 7y ago
        Much of the work could have been done ahead of time.
• tempsolution 7y ago
  Wow that is some bad management. For 15 years they say nothing and then they give a whole half year for people to migrate. The reason why people did not migrate is because it is a huge effort and as long as python 2 still is being developed, why bother? The right thing to do would have been to immediately deprecate python 2, only supply security fixes and tell them in 2010 or so that support will run out in 2015 or, well 2020. But this is just crazy.
• Wheaties466 7y ago
  python 2 will continue to run on production systems for at least another decade, thanks to centos6 and making it basically impossible to upgrade to python3 as the main python binary on the system without completely breaking everything.
• carapace 7y ago
  Going forward, I'll be maintaining Python 2.7 for the indefinite future. This will be under project name "Bladders". (Python is named after Monty Python's Flying Circus. There is another fantastic British comedy called Black Adder, and the main character is sometimes called "Bladders" as a contraction of Black Adder.) Unlike Tauthon, I won't change the language at all, only maintenance. I'm also going to make a curated software repository of Python 2 code, starting with the standard lib and some common third-party packages (like Snakefood.) And I'm going to pay technical writers to clean up the documentation. I don't give a fig about controversy. I just want to keep using Python 2.
  • ARandomerDude 7y ago
    Out of curiosity, what is it that you like about Python 2? Not attacking you, just curious. I've never used Python professionally (mostly Ruby and Clojure), so I don't have a horse in this race.
    • carapace 7y ago
      Cheers! Answering you for all three (at the moment) comments asking: Okay, here goes. In brief, Python 3 adds work without adding significant (to me) value. As others have pointed out, you don't get anything from converting an existing project from 2 to 3 other than compatibility with 3. If the Python 3 proponents were to succeed in killing 2 then that becomes compelling, however, since I intend to maintain 2, I don't care about compatibility with 3. As I have become older my tastes have changed, and nursing an old friend seems easier and more fun than trying to stay up to speed with the new hottness. Especially since it just isn't that hot. Some details: First, I see 2 and 3 as different languages. The degree of similarity is not relevant (to my evaluation of which to use) since they are incompatible (in other words, incompatibility is binary not scalar.) Since the abdication of the BDFL it seems to me to be even more appropriate to treat them as separate. I don't know how or why but Guido was good at language design. I feel like he lost his touch somehow, and then he left anyway, so the magical "thing" that made Python so sweet in the first place is gone. (I won't comment on any particular PEPs. It's all been said by others elsewhere.) I feel that Python 2 hits a sweet spot in language design as compared, not just to other Python versions, but to other languages as well. (If you can't use Lisp or Smalltalk or Prolog at least you have Python.) Python 2.7 is a local optimum with a clear view and steep sides, eh? Python 3 goes crashing down the hill and into the woods... From this POV the cessation of modification to Python 2 is a boon. It's stable and can only get asymptotically more so over time. It also means that projects like Snakefood that do meta-programming can stabilize because the underlying language is stable. We are only now getting type checking and such, and e.g. MyPy has to expend resources to deal with changes to Python 3 or risk bit-rot. Python 3 continues to include dubious design decisions that then must be dealt with by other projects/tools. I.e. syntax highlighters have to be modified to deal with "fstrings", etc. It drives a continuous process of change for the sake of change without introducing anything fundamentally new and useful. As a developer, your knowledge is depreciating as you sit there because the language is in flux. With Python 2 the thing you're studying and using is stable. In fact, it's possible that the total amount of code could contract in a stable regime. Especially if you have dev time to work on it (that isn't wasted on pointless new features that then engender additional work to learn and use.) You can also spare cycles to work on things like improving the standard library documentation, or the packaging/versioning mess, or really anything other than tweaking the language (and, again, making more work for everyone without adding fundamental new facilities.)
• sedatk 7y ago
  They took too long and that’s one of the factors making the sunset harder today. They should have ripped the band-aid 10 years ago.
• ericfrederich 7y ago
  I hope the Raspberry Pi community really switches to Python3 soon. I've looked at the PiStorms stuff MindSensors (Lego Mindstorms compatible). Unfortunately it all seems to be just Python2 based. Looking at all the code it seems you're always basically running your own event loop (infinite while True: loop). I think it'd be really awesome to utilize Python 3's asyncio package to write more event driven programs. Writing code in asyncio is basically a different paradigm. It's not like Golang where you can write a function and not care if someone is calling it synchronously or starting a goroutine with it. With Python asyncio it seems for every good library out there someone has a create an asyncio version of it. For instance "requests" vs. "aiohttp". So, while embracing Python 3 still wouldn't get me what I ultimately want, it's a first step in the right direction.
  • darpa_escapee 7y ago
    > For instance "requests" vs. "aiohttp". "asks" implements a requests-like interface over asyncio/trio.
• hiccuphippo 7y ago
  I checked my system (Archlinux) a few weeks ago and the only things with Python2 dependencies where the Gimp and Calibre. Kudos to everyone who has worked on the migration over all these years.
• ascotan 7y ago
  I wonder if there is an interesting lesson learned here for future language maintainers. One of the reasons for the 14 year deprecation windows (imho) is that the language maintainers didn't have control over much of the core platform libraries/ in everyday use. This created a lot of community angst against the upgrade path.
• jondot 7y ago
  What I hate about this document is part of a bigger problem I see with the Python community. It's written like a hate letter with a passive aggressive tone of finger pointing towards users of Python as the source of the never-ending Python 2-3 split. It says, between the lines: "YOU are part of the problem, stop using Python 2. We don't care about YOU anymore. Stop using Python 2". I can think of ten other different ways to be more constructive and, generally, nice.
  • ausbah 7y ago
    It's been 10+ years, they're just being a matter of fact.
• darknoon 7y ago
  One of the more annoying aspects of the Python 2 to 3 transition is with large movie / video production houses, eg Pixar. Their USD library only supports Python 2, since they aren't interested in supporting Python 3. I wonder if that will change next year. The "industry standard" platform is only just getting around to switching to Python 3: https://vfxplatform.com https://vfxplatform.com
• formatkaka 7y ago
  Python 2 was the language through which I was introduced to programming. My first love in this field !! Adios
• vkaku 7y ago
  Wow. I still found some inadequacies with six, such as support for bytes/b, datetime (timestamp) and SimpleHttpServer Overall, didn't have too many issues with the conversion but this stuff is going to hit some companies harder than others. I can tell that it's worth the migration, end this blood fest once and for all.
• sullyj3 7y ago
  The fact that ubuntu's (and by extension, most WSL installs') default python is python 2 is crazy, and definitely not helping the situation.
• yters 7y ago
  If it weren't a forced update, I personally have not found much in Python 3 that is a benefit over 2. It seems the unicode support is the big change, but I just use ASCII encoding, so unicode doesn't matter to me.
  • diminoten 7y ago
    > but I just use ASCII encoding No you don't! :D
    • yters 7y ago
      Search for 'default' https://docs.python.org/2/howto/unicode.html https://docs.python.org/2/howto/unicode.html
      • diminoten 7y ago
        Thought you meant 3, not 2.
• musicale 7y ago
  This would never have been such an unpleasant issue if Python 3 hadn't broken backward compatibility in very annoying ways; one of the more inexcusable examples was removing the print statement, a convenient piece of syntax that dates to antiquity, and which could have peacefully coexisted with the print() function in Python 3. Now that Python no longer has a BDFL, maybe we'll get the print statement back? ;-p
  • acdha 7y ago
    That’s something which takes literally seconds to safely fix across an entire project using modernize/futurize, along with the better exception handling syntax, etc. It’s just not worth clinging to the past at this point.
  • gnulinux 7y ago
    You can fix that programmatically.
• Railsify 7y ago
  Finally. The transition is not hard, just time consuming, just split the work among the team and force everyone to make a little progress each day.
• jimmaswell 7y ago
  I'll never forgive the loss of the convenient print statement and easy string handling. So much for "practicality beats purity." At least most of the other new stuff is good.
• presidentscroob 7y ago
  Maybe Python 2 can go away soon. Also, modern Python 3 support isn't even close to 100% either. https://pyreadiness.org/3.7/ https://pyreadiness.org/3.7/
  • duckerude 7y ago
    That website is interesting, but maybe not as significant as it initially appears. In some sense chardet doesn't explicitly support Python 3.7, but it's packaged for it in Debian Stable. I wouldn't expect any problems. more-itertools is listed in white simply because it doesn't use any granular version classifiers on PyPi. It only has a python_requires setting, which is authoritative. It's plausible that every single package on that page supports Python 3.7 in practice.
• thuylun2412 7y ago
  waoo
• zacky777 7y ago
  I still want to keep using Python 2.
• vadikkiev 7y ago
  Thank you very much for the news, it was useful to me
• lucaspottersky 7y ago
  sounds like they should probably sunset Python 3 instead
• s_kunk 7y ago
  Protip: 2to3
• jrykbtest 7y ago
  Finally, print is no longer a reserved keyword!
• swebs 7y ago
  When will OS vendors stop defaulting `python` to Python 2? It seems like an unnecessary trap that pushed new developers to an out of date version. Even Ubuntu 19.04 defaults to Python 2.7.16
• Tempest1981 7y ago
  Last I checked, macOS doesn't include python3, just python2. I wrote a handy tool for our team, but nobody uses it because they don't have python3. Now I have to play sysadmin on dozens of machines. A few had 3.5, but I used 3.6. What can be done to make this easier? I.e. why isn't python3 pre-installed by now? esp 3.6 or 3.7?
  • nvrspyx 7y ago
    Because Apple is notorious for using outdated libraries in macOS, like OpenGL. They included Python, but it was never a real focus to stay up to date since it was primarily to support legacy software. With that said, Apple will not be including Python (or the other scripting languages like Ruby or Perl) at all starting with Catalina.
• speedplane 7y ago
  Python 2 to 3 comments can be boiled down to three constituencies: 1. Native Python 3 Developers: It's great over here, what's the problem? 2. Python 2 Developers Migrating a Small App: It barely took me any time, you Python 2 developers are lazy and inhibiting progress! 3. Python 2 Developers Migrating a Large App: Ugh.
• wedesoft 7y ago
  Really difficult to track are issues caused by things like the map function now returning an iterator object. I.e. the content of the iterator is empty on second use. Python 3.4.3 (default, Oct 14 2015, 20:28:29) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> x = map(lambda v: v + 1, [1, 2, 3]) >>> list(x) [2, 3, 4] >>> list(x) []
• trustlyppp 7y ago
  I have suffered a lot when it come to relationships and even when I was married,that is why I want to give thanks to Papa Egbe for bringing back my husband.I was the world’s biggest skeptic.I never believed in magic spells,but I was told by a very close friend that Papa Egbe is gifted with spiritual powers,My love life was in shamble,my husband didn’t seem to care or love me and break up our relationship.I was confuse and do not no what to do again,rather then to get in contact with Papa Egbe.He did a love spell that make my husband come back to me.we are now very much happy with our self.Papa Egbe make him to realize how much we love and need each other.And he can help you with the following problems:Court Case.Reading.Bad Dreams.Promotion in your office.Financial Assistance.Herbal cured for Herpes Simplex Virus.Lottery Spell.Love Spell.contact Papa Egbe on papaegbeherbalhome @ gmail . com.Papa Egbe brought happiness to my home.