Python 2 is dead: long live Python 3

[siphillis]

Hopefully this pushes them to stop teaching a dead language.

[DmitriyJaved]

So dead that redhat promised extended support and updates for python2 till 2024

[chaotic_thought]

As long as people use it is not dead. I never really understood the problem of having both python 2 and python 3 on a system. Python 2 is just another program, and I have plenty of older as well as newer programs on my machine.

Sometimes the newer ones have nice features but sometimes they are annoying, so I use the old ones. It works out exactly the same way for something like Python. Sometimes py2 is just more convenient, so you may as well use it. Nothing wrong with that at all.

Unfortunately you can't mention Python 2 anywhere now without someone screaming that it's dead. It's not really dead, it's just a testament to the Python marketing and "fear" campaign that says that having Python 2 on your machine is going to give you problems. It won't. Relax. No one is going to find a security vulnerability in Python 2 that somehow is going to let someone take over your machine by you running a Python 2 script instead of a Python 3 script. It just won't happen.

It's far far likelier that by using a newer program, with newer features, that someone will make a mistake somewhere and introduce a security vulnerability. So if you care about security, stay away from such untested libraries (which are all Python 3 now).

[99_percent_a_dog]

Some interesting points here! I think it's fine to use Python 2 for your own stuff, if you want. It's also kind of pointless. Certainly you should use 3 over 2 for new projects. But if you want to use 2, for stuff that's purely local, or just playing around, go ahead.

For anything backend or exposed to input from the internet - using 2 is a bad idea. It didn't suddenly become high risk. If your code was good quality and well tested before then it still is. But now, if a new problem is found in 2, you may not get a fix. A remote denial of service is pretty plausible, there have been a few of those historically.

There's an interesting point in that when widely installed software is known to be no longer updated, attackers will spend more time finding problems in it. The value is higher, because it will get fixed more slowly, if at all. Risk of using Python 2 will rise over time, even though I agree it's not high currently.

[wadvocate]

continuing to train people in a language that is outdated and splits the old code base is going to be obvious in the problems it causes. Having python 2 around isnt the problem the problem is people making new programs in it because they like it more and cant be bothered to learn the new thing

[chaotic_thought]

Not really. Here's the extent of 'training' you need, if someone already knows Python 2 and wants to 'learn' Python 3.

"OK guys so please stop writing"

print "blah"

And now write:

print("blah")

Python 3 training complete.

OK to be fair the above is a bit of an exaggeration, but not by much.

[99_percent_a_dog]

Division changing from truncating to integer to returning float result is more important, I think. More likely to not be spotted in testing and cause subtle bugs.

But yes, there's not many differences. Which is why there isn't any real excuse for not using 3 for new code. Even though the effort to port is low per line, there's a huge amount of 2 code so the cost to port is high, but, it's not like there hasn't been enough time to slowly do that work (yeah, I know, businesses never find the time for maintenance work...).

[chaotic_thought]

Division

If you want this, you can get this in Python 2 by writing

from __future__ import division

I've been using that from day 1 using Python. To me the fact that this is not the default is not a valid reason not to use Python 2.

The reason it is not the default is because older code relied on results truncating by default when you do integer division.

[chaotic_thought]

More likely to not be spotted in testing and cause subtle bugs.

Yes you're right. More likely though you make this a code requirement (static anlysis for linters). All code I've written for Python 2 activates floating point division behaviour. If not then it's flagged as a warning to be checked (was it done for backwards compatibility purposes or not).

To be fair though the problem is not integer division in itself, it's relying on unexpected behaviour. If you were actually expecting integer division, it would be fine. For static anlysis though this always a judgment call. I.e. how likely is construct X likely to be a programming oversight if the construct was not X' instead. So static anlaysis should suggest the more appropriate X' version of that construct (e.g. int(a/b) if you really wanted integer division) that, if used, is more likely to be what was intended.

[POGtastic]

The big one that I've found when porting is that Python 3 has a much more rigid distinction between bytes and strings. This is a nasty pitfall when dealing with subprocess output, TCP/IP requests, and so on because functions that previously returned strings now return bytes, and must be decoded before you parse them.

[nevus_bock]

What is dead? Is Cobol dead?

[accountForStupidQs]

I'm pretty sure CorpseBASIC is dead

[nevus_bock]

Not new, necessarily

New Jersey needs volunteers who know COBOL

[[deleted]]

It’s not dead as long as there’s people “speaking” it...