str vs bytes isn't as bad as people make it out to be. You'd be used to it within a week. The other stuff is mostly just semantic changes like range vs xrange or dict.items() returning an iterator now vs a list.
At this point, the bigger issue might be learning all of the new features people were missing out on by not moving earlier, like asyncio.
If you have a large python2 project with 100 dependencies, will all of those have python3 versions? And will they be compatible with each other in the ways your current dependencies are?
[1] A one that I often seen was MySQL-python. That package hasn't been touched since 2014. Another one I've seen was PIL, that one was last released in 2009, and isn't even on PyPI, because it is that old, fortunately maybe because it's not on PyPI, people are more aware of Pillow which is a drop in replacement
It's not easy to determine which versions of the library to upgrade to however. What's the latest version compatible with both python 2.7 and 3.7. Would be nice if pip had a setting to get that.
From there, you use the built-in documentation, learn your way around the language, and end up with Python 2.7 as your daily driver.
You have to know to write "python3" to get Python 3. In effect, it's not the default, it's the special alternate version.
Show them the EOL document, and ask them if they can afford to have their systems owned when an exploit is released for Python 2.7 that goes unpatched because the project is unmaintained.
It's easier to start new projects in a supported version, than it is being forced to port your applications at the 11th hour after exploits in unmaintained Python versions are found.
From a developer's perspective, you're coding in a time machine with Python 2.7. Updates to community packages from the last decade haven't been backported to their Python 2.7 versions, so you'll run into an accumulation of bugs at every turn. If you're interfacing with an API, you probably won't find an off-the-shelf solution for Python 2.7 like you would Python 3. You are literally creating more technical debt with every line of Python 2 that you write.
You are agreeing with your parent:
> And at that time it will be non-trivial (to say the least) to fix every affected script and the entire downstream dependency chain because — as so many on HN know — Python 3 is a different language.
Why are people choosing 2.7 for new projects when there is a time bomb coming up? Several years ago, you could blame the Python folks for this break, but once 3.3 (or perhaps 3.5) was out, there was no good reason to start new projects in 2.7, especially when it was publicized that the language will be EOL.
- You won't be able to use newer versions of open-source libraries or newly-developed libraries (including both new features and security updates - note also that a project's developers won't be looking for security bugs in old versions of libraries and likely aren't supporting old versions, but attackers probably are looking for them!)
- Your company ends up with two sets of code in effectively two different languages, and you can't extract common libraries, reuse tested business logic, etc.
Those are things the business is likely to care about. It would be particularly helpful if you can show that you were unable to use the new thing because you had existing code in Python 3. or the new thing was unable to use new features of the libraries they depend on.
Do you have a security team who cares about running supported versions of software or vulnerabilities in deployed software? Can you find libraries in their `pip freeze` that have had security updates that weren't backported to the Python 2 version?
Have you had problems when a team using one Python interpreter needs to call code written by a team using another interpreter?
Writing new projects in Python 2 is rather like writing new projects in Visual Basic 6, in that it will certainly still work in 2020 and technically it's easy to get started - except with the advantage that 2 and 3 are actually quite similar languages. If your company would try to pressure folks writing in VB 6 to use something else (VB.NET? Qt? Electron?), imagine you're in that situation, except it's magically much much easier to do the port.
Python 2 doesn’t sound like an ancient, totally-different-language so people just adopt it because it was the version on their laptop or something and because it “works”. In reality, it’s inevitable that some major IT upgrade will finally throw out that interpreter (or, the existing one will fail to work for some obscure reason and no one will fix it because it’s “unsupported”). And at that time it will be non-trivial (to say the least) to fix every affected script and the entire downstream dependency chain because — as so many on HN know — Python 3 is a different language.
Any ideas on how to present this to management as the crisis that it should be? It’s really quite a risk but it is hard to demonstrate the risk when everything “works” so “well” right now.