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.
By experience, people with large Python projects often overblown the difficulty of porting in their head. Unless you have a very rare irreplaceable dependency or some terrible C extension, porting is easy.
It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones. It's just not stuff what had be sold to the public. People want to hear about better perf or fancy features, not better error messages or banned logical errors.
The hardest code base I saw ported was the Twisted project. It's a good counter example: it was long, hard, and required very gifted people (thanks Hawkowl !).
But most projects are not like that. They are full of dumb operational logic that can be ported 80% by 2to3, and a bit of manual fix.
The fact is, people love to complain, so you will hear massively people with that particular example from the movie industry, or this guy who coded this Fortran extension that was in such a tough situation. Well guess what, that's not what most migrations are about.
Most migrations are Django/flask websites, math teachers exercises, physicists scripts, sysadmin tools, etc. Straightforward stuff. I should know, I've been moving from industry to industry for 10 years, all my clients are different, but most of them end up with similar stuff in their repo because Pareto is a thing.
Nonetheless, the screams from the first ones scared the later.
> 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.
One of the easiest compared to what? Certainly not a Python point release. A couple of points:
1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't.
2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining.
(I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came out, I maintain that a) the transition was botched b) core dev did not listen to any of the problems people pointed out for _years_.)
To give you an idea of what botched means: several people, names withheld to protect the guilty, had to wade in 6 months worth of shit to get a 2.x release that made TLS vaguely OK, in, like, 2014?
> python 2 to 3 (at least by 3.3 or so) was one of the easiest transitions I've ever done.
Good for you. Some of us had code bases of considerable size and complexity though.
The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg, then python 3 was not a help at that point for something already in service. It was just more cost for no benefit.
> If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.
These aren’t exchangeable. Why do people on the internet think bitching (either constructive or not) is some valuable currency? Often times the people complaining had no means or position to of the work. 4 promotions later I sure as hell wasn’t going to participate in that 2 to 3 mess on a project produced years ago, but I could still opine in the situation. I also had little incentive to fund it.
Your analogies are bizarre. No idea what you’re trying to convey with philips v torx but I’m going to wager it’s explanatory power in this case is shit anyway. I can still demolish it, having actually worked in manufacturing there were times we told a supplier (ie Python) to fuck off and piss up a rope because what they were proposing was not compatible with our existing tooling and it would be too costly to convert for little benefit to us.
I respect apples prowess in the consumer space, but there’s a reason you don’t see their products regularly put into industrial roles where your timeline is more than 5 years. Apple products are disposable, many applications in industry are expected to last. Python is a general purpose programming language (or at least billed itself as such). Your comparison is poor.
[not speaking on behalf of any employer, opinions my own]
I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Even if it only takes ~5 minutes per module to make the changes and validate that it works correctly, this becomes a giant undertaking when you have tens of thousands of files to migrate.
The fact that it takes a long time also creates other problems. Your business isn't going to hit "pause" on other development, so there will be changes constantly introduced into modules you've already "swept". It's going to be hard to make sure 100% of your engineers and code reviewers are knowledgeable about the specific requirements to make sure the code works in both 2 and 3, so you would really like some automated safeguards to make sure they don't introduce anything that won't work in 3. Pylint helps with this, but won't catch everything. Unit tests are obviously essential, but:
1. Even a well-tested project won't have tests that cover 100% of code paths and behavior.
2. You're stuck running the tests on both python2 and python3 for the duration of the migration, which doubles the resource (compute, memory, etc.) cost of your Python CI and regression testing infrastructure for the duration of the migration.
I see far too many commenters attributing the delayed migration to laziness or complacency. In reality, most big companies have passionate Python advocates who really want to be on Python 3, but the scale of the problem and the lack of tooling to tackle it with a sub-O(n) amount of effort make the overall project risky and expensive for the business.
As one of the complainers, my time wasn't ever going to go into fixing third party libraries. Instead, I spent my time moving to languages that had more respect for their invested users.
Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that you now need to change out all your hand tools, manufacturing lines, assembly robots, and equipment from multiple vendors from phillips to torx all at once. Sure, you can do some prep work, but you've got to coordinate a cutover at some point, in sync with tools that you have no control over or have to recreate from scratch. All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.
(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...)
I had exactly _zero_ blocking issues. The only relevant thing for me is that I keep reaching for StringIO and urlparse (and friends) and they're used differently now.
_Everything_ I relied upon, every single dependency in my projects, gradually migrated over the course of a year and nothing broke.
Furthermore, I now have asyncio, aiohttp and friends to play with, and it's been pretty good.
If you were writing major libraries that needed to work on both 2 and 3 like many of us were, I suspect your opinion would be different. It was never a case of 'oh we'll just switch to 3 now' because that's not at all how it worked.
> If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.
Yeah, right. Look at the creator of Python himself. Took about 3 years to migrate just his employer, and that's a top-tier software shop [1].
I've heard many people talk like you over the years, always being dismissive of the cost to others in python 2 vs 3. The complaints against the migration were not unfounded.
Let me put it this way: at $dayjob, where 'IT' isn't particularly specialized, we just celebrated a switch to SQL Server from a homegrown database written in the early 80ies.
I wager that in many cases, fixing something that isn't broken never reaches the top of the TODO.
> (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...)
Totally disagree. There's rarely a good reason to break backwards compatibility. It's beyond rude to choose to break compatibility and then force all your users to fix it.
The Apple comparison is a bad one since Apple controlled the whole thing.
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
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.
>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...
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.
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?
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?
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.
If they are using PyPI, the project should be specifying which versions it supports in either setup.cfg or setup.py[1].
For example, I decided to only support Python3 going forward. I've had person once open a PR to add python2 support, but I politely declined[2]. As such, PyPI shows that only 3.5+ is supported[3].
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.
Recently I ran into a Python script on GitHub that I couldn't get to run on 2 _or_ 3.
Both errors were familiar from earlier cases of trying to run with the wrong Python version, but I have no idea how the code managed to do that for both, and frankly it wasn't worth the effort to look into.
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.
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.
"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.
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.
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
When people mock me for writing long-term projects in Perl 5 (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.
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.
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.
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.
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).
[+] [-] ken|6 years ago|reply
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.
[+] [-] sametmax|6 years ago|reply
It's tedious yes. Boring even. But most projects get away with 2 weeks of investment. And yes, it pays back. Python 3 is a vastly superior language when it's about introducing less bugs or debugging existing ones. It's just not stuff what had be sold to the public. People want to hear about better perf or fancy features, not better error messages or banned logical errors.
The hardest code base I saw ported was the Twisted project. It's a good counter example: it was long, hard, and required very gifted people (thanks Hawkowl !).
But most projects are not like that. They are full of dumb operational logic that can be ported 80% by 2to3, and a bit of manual fix.
The fact is, people love to complain, so you will hear massively people with that particular example from the movie industry, or this guy who coded this Fortran extension that was in such a tough situation. Well guess what, that's not what most migrations are about.
Most migrations are Django/flask websites, math teachers exercises, physicists scripts, sysadmin tools, etc. Straightforward stuff. I should know, I've been moving from industry to industry for 10 years, all my clients are different, but most of them end up with similar stuff in their repo because Pareto is a thing.
Nonetheless, the screams from the first ones scared the later.
[+] [-] sdoering|6 years ago|reply
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.
[+] [-] lvh|6 years ago|reply
1. Python core dev pretended Python 3 was good and ready by, like, 3.1. It wasn't.
2. While your problem may have been painless (I'm glad), that doesn't mean that everyone who complained was just complaining.
(I use Python 3 as the default now, but as someone intimately involved with an async IO library at the time it came out, I maintain that a) the transition was botched b) core dev did not listen to any of the problems people pointed out for _years_.)
To give you an idea of what botched means: several people, names withheld to protect the guilty, had to wade in 6 months worth of shit to get a 2.x release that made TLS vaguely OK, in, like, 2014?
[+] [-] ofibrvev|6 years ago|reply
Good for you. Some of us had code bases of considerable size and complexity though.
The fact is that for working software on the python platform, this upgrade represented work that had to be done that for a legacy app that was still chugging... little benefit. If you already coded around the python 2 limitations for Unicode eg, then python 3 was not a help at that point for something already in service. It was just more cost for no benefit.
> If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.
These aren’t exchangeable. Why do people on the internet think bitching (either constructive or not) is some valuable currency? Often times the people complaining had no means or position to of the work. 4 promotions later I sure as hell wasn’t going to participate in that 2 to 3 mess on a project produced years ago, but I could still opine in the situation. I also had little incentive to fund it.
Your analogies are bizarre. No idea what you’re trying to convey with philips v torx but I’m going to wager it’s explanatory power in this case is shit anyway. I can still demolish it, having actually worked in manufacturing there were times we told a supplier (ie Python) to fuck off and piss up a rope because what they were proposing was not compatible with our existing tooling and it would be too costly to convert for little benefit to us.
I respect apples prowess in the consumer space, but there’s a reason you don’t see their products regularly put into industrial roles where your timeline is more than 5 years. Apple products are disposable, many applications in industry are expected to last. Python is a general purpose programming language (or at least billed itself as such). Your comparison is poor.
[+] [-] alexhutcheson|6 years ago|reply
I think many people underestimate the challenge that the 2 to 3 migration presents for large enterprises. The core issue is that even though the migration for any given module is normally really easy, the total effort required to migrate is still essentially O(n) in module count/file count, because even with current tooling you still need to have an engineer look at every module to do the change safely. Even if it only takes ~5 minutes per module to make the changes and validate that it works correctly, this becomes a giant undertaking when you have tens of thousands of files to migrate.
The fact that it takes a long time also creates other problems. Your business isn't going to hit "pause" on other development, so there will be changes constantly introduced into modules you've already "swept". It's going to be hard to make sure 100% of your engineers and code reviewers are knowledgeable about the specific requirements to make sure the code works in both 2 and 3, so you would really like some automated safeguards to make sure they don't introduce anything that won't work in 3. Pylint helps with this, but won't catch everything. Unit tests are obviously essential, but:
1. Even a well-tested project won't have tests that cover 100% of code paths and behavior.
2. You're stuck running the tests on both python2 and python3 for the duration of the migration, which doubles the resource (compute, memory, etc.) cost of your Python CI and regression testing infrastructure for the duration of the migration.
I see far too many commenters attributing the delayed migration to laziness or complacency. In reality, most big companies have passionate Python advocates who really want to be on Python 3, but the scale of the problem and the lack of tooling to tackle it with a sub-O(n) amount of effort make the overall project risky and expensive for the business.
[+] [-] skywhopper|6 years ago|reply
Also, your screwdriver analogy makes no sense. The choice here is not about "your favorite tool brand". Mixing and matching tool brands is straightforward. The more appropriate analogy with screwdriver heads would be to imagine that you now need to change out all your hand tools, manufacturing lines, assembly robots, and equipment from multiple vendors from phillips to torx all at once. Sure, you can do some prep work, but you've got to coordinate a cutover at some point, in sync with tools that you have no control over or have to recreate from scratch. All for zero benefit in the end, other than the hope that they don't make the same mistake again with Python 4.
[+] [-] wiglaf1979|6 years ago|reply
That seems like a very specific example...
[+] [-] rcarmo|6 years ago|reply
_Everything_ I relied upon, every single dependency in my projects, gradually migrated over the course of a year and nothing broke.
Furthermore, I now have asyncio, aiohttp and friends to play with, and it's been pretty good.
[+] [-] linuxftw|6 years ago|reply
> If people spent half as much energy upgrading as complaining, this would have gotten done 5 years ago.
Yeah, right. Look at the creator of Python himself. Took about 3 years to migrate just his employer, and that's a top-tier software shop [1].
I've heard many people talk like you over the years, always being dismissive of the cost to others in python 2 vs 3. The complaints against the migration were not unfounded.
1: https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one...
[+] [-] brnt|6 years ago|reply
I wager that in many cases, fixing something that isn't broken never reaches the top of the TODO.
[+] [-] riazrizvi|6 years ago|reply
[+] [-] alanfranz|6 years ago|reply
I suppose you don't use Java.
[+] [-] eru|6 years ago|reply
Isn't what code review and CI/CD is for?
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] pbreit|6 years ago|reply
The Apple comparison is a bad one since Apple controlled the whole thing.
[+] [-] m463|6 years ago|reply
[+] [-] inatreecrown2|6 years ago|reply
[+] [-] drej|6 years ago|reply
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
Are there plans to add a banner to Python 2's docs? I think it would be quite instructive.
[+] [-] jedberg|6 years ago|reply
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.
[+] [-] coldtea|6 years ago|reply
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...
[+] [-] carapace|6 years ago|reply
I don't give a fig about controversy. I just want to keep using Python 2.
[+] [-] Animats|6 years ago|reply
[1] https://www.hostgator.com/help/article/what-software-and-pro...
[+] [-] EnderMB|6 years ago|reply
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?
[+] [-] tibbon|6 years ago|reply
[+] [-] toyg|6 years ago|reply
[+] [-] umvi|6 years ago|reply
For example, I decided to only support Python3 going forward. I've had person once open a PR to add python2 support, but I politely declined[2]. As such, PyPI shows that only 3.5+ is supported[3].
[1] https://github.com/RPGillespie6/fastcov/blob/master/setup.cf...
[2] https://github.com/RPGillespie6/fastcov/pull/11
[3] https://pypi.org/project/fastcov/
[+] [-] reilly3000|6 years ago|reply
[+] [-] StavrosK|6 years ago|reply
[+] [-] MzHN|6 years ago|reply
Both errors were familiar from earlier cases of trying to run with the wrong Python version, but I have no idea how the code managed to do that for both, and frankly it wasn't worth the effort to look into.
[+] [-] gigatexal|6 years ago|reply
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.
[+] [-] voldacar|6 years ago|reply
[+] [-] avian|6 years ago|reply
https://www.archlinux.org/news/python-is-now-python-3/
[+] [-] sametmax|6 years ago|reply
[+] [-] voldacar|6 years ago|reply
How many more decades must we wait??
[+] [-] _salmon|6 years ago|reply
[+] [-] mixmastamyk|6 years ago|reply
[+] [-] alerighi|6 years ago|reply
Or use a Linux distribution like Arch that has python symlinked to python3 by default.
[+] [-] cm2187|6 years ago|reply
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|6 years ago|reply
[+] [-] choppaface|6 years ago|reply
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-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.
[+] [-] chirau|6 years ago|reply
[+] [-] intea|6 years ago|reply
More like 12 years by now :-)
[+] [-] jwr|6 years ago|reply
To clarify: long-term means automotive time scales: I want to be able to run my software in 10 years.
[+] [-] ssully|6 years ago|reply
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
[+] [-] sweettea|6 years ago|reply
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
[+] [-] thefabsta|6 years ago|reply
I am, however, very happy to see that ROS2 (the next iteration of ROS) uses Python 3 by default.
[+] [-] sireat|6 years ago|reply
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?
[+] [-] nickjj|6 years ago|reply
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/
[1]: https://nickjanetakis.com/blog/upgrading-a-dockerized-flask-...
[+] [-] adamhepner|6 years ago|reply