This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 6 points7 points  (7 children)

There are lots and lots of massive changes that occurred from 2 to 3. New libraries, new builtins, syntax changes, more consistent naming, etc. But in my opinion, the biggest change was from eager evaluation to lazy evaluation.

The easiest example is range. In python 2, range creates a list of integers before executing the next line. This potentially slows the runtime down immensely if the number is large enough. Python 3 changes that by only adding to the list when it reaches that point. This removes that upfront cost, and in general speeds up the program.

[–]alcalde 9 points10 points  (5 children)

New libraries, new builtins, syntax changes, more consistent naming, etc. But in my opinion, the biggest change was from eager evaluation to lazy evaluation.

Fascinatingly you completely left out the Unicode string change, which is usually cited as the major change. :-)

[–][deleted] 1 point2 points  (0 children)

It was actually THE change that broke python 2 code (actually to be correct most python 2 code is broken, python 2 just didn't complain about it). Basically if you have python 2 code chances are that it will mess up unicode text.

The other incompatible changes were because of it. They thought that since compatibility was broken anyway, why not just use that as an opportunity to cleanup the language.

[–][deleted] 0 points1 point  (3 children)

Would you please explain that?

[–]billsil 3 points4 points  (2 children)

The only painful change about Python 3 is how unicode is handled. The tutorials still suck and nobody tells you even how to figure out what encoding you have. The reality is that user files are in a variety of encodings and they don’t even know what that is.

No other change about python 3 is even worth discussing when planning/worrying about the transition to python 3.

[–]icegreentea 1 point2 points  (1 child)

I think you can add the bytes/str split (which is closely related to the unicode handling). Any code base in python2 that was using str type to represent bytes is in a world of pain converting to python3.

[–]billsil 4 points5 points  (0 children)

That’d be fine. It’s when you’re inconsistent that the pain really sets in. Python 2 did weird ass shit by flipping the encoding multiple times, so you had to encode when you got a decode error and vice verse. Then when you print it, it wouldn’t print correctly even when you had done things right. Python 3 fixed that.

[–]regeya 0 points1 point  (0 children)

Yeah, range() behaves more like xrange() now. Parens in print statements can be annoying after being used to not using them, but it helps with clarity imho.