4 ms·

It frustrates me that even now I regularly find out about some new thing being written at work, only a few months old but already fairly widespread among intern

It frustrates me that even now I regularly find out about some new thing being written at work, only a few months old but already fairly widespread among internal teams, and...oh, they chose Python 2.7. We not only have Python 3 available but several versions of it, too. 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.

jeffrallen 6y ago
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.
- zamadatix 6y ago
  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.
  - deleted 6y ago
    [deleted]
- monadic2 6y ago
  Lost time? How do you figure?
- BeetleB 6y ago
  > 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.
xxpor 6y ago
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.
- shoreofwonder 6y ago
  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?
  - monadic2 6y ago
    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.
  - SiempreViernes 6y ago
    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?
  - user5994461 6y ago
    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.
  - takeda 6y ago
    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
geofft 6y ago
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.
- joshuamorton 6y ago
  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.
  - jart 6y ago
    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.
jlokier 6y ago
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.
- p_l 6y ago
  A lot of the time, the systems people work with still default to python2 with python3 requiring special care just to install.
heavyset_go 6y ago
> 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.
mbar84 6y ago
Please have a look at lib3to6, I hope you find it useful to convince them to stop writing for Python2.7 only.

jeffrallen 6y ago

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.

zamadatix 6y ago
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.
- deleted 6y ago
  [deleted]
monadic2 6y ago
Lost time? How do you figure?
BeetleB 6y ago
> 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.

xxpor 6y ago

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.

shoreofwonder 6y ago
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?
- monadic2 6y ago
  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.
- SiempreViernes 6y ago
  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?
- user5994461 6y ago
  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.
- takeda 6y ago
  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

geofft 6y ago

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.

joshuamorton 6y ago
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.
- jart 6y ago
  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.

jlokier 6y ago

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.

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

heavyset_go 6y ago

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

mbar84 6y ago

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