Hacker News Reader

I really think the "Python 3 is a different language" stuff is overblown.

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.

The syntax differences are indeed minor. But dependencies are not.

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?

Sure, but even that is dwarfed by the equivalent problems in the ruby community. Most gems die after X years. Ironically some part of this must be explained by Python's enormous popularity.

Not wanting to update dependencies is fine, but in that case I'm not sure how it's an issue that you also have to use a certain version of the interpreter?

There is a pretty good chance they all have a python 3 version.

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.

At this point all packages work with Python 3. If you use ones that don't, they are not maintained, and you shouldn't use them.

[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

Maybe it's the fact "python" usually runs Python 2.7 on modern systems.

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.

A lot of the time, the systems people work with still default to python2 with python3 requiring special care just to install.

> Any ideas on how to present this to management as the crisis that it should be?

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.

It's not a crisis. If Python 2.7 works, people will keep using it. The real crisis is all the lost time dealing with porting to Python 3.

Middle English still works too doesn't mean it's not a problem to try to use it for a new project. Everything has trade offs, both staying on the old AND moving to the new. At some point everyone does move and managing the size of that transitional tail well is part of running a business well. There is not a one stop answer to the problem of when to migrate to the new and stop using the old but "always bleeding edge" and "always what we started with" are unlikely answers for most places.

Lost time? How do you figure?

> The real crisis is all the lost time dealing with porting to Python 3.

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.

The primary practical effects of staying on Python 2 are

- 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.

Also, and importantly, you can port file by file (if you use six and test on both versions). That's much more incremental and safer than a port by rewriting.

Yeah at my old job I had to write code in Python 6. I can tell you it's even worse than Python 2 and 3 combined.

Please have a look at lib3to6, I hope you find it useful to convince them to stop writing for Python2.7 only.