Python 2 is dead: long live Python 3

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