On Wed, Apr 16, 2014 at 12:51 PM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > Converting "print spam" to "print(spam)" is the trivial part of it. The > biggest change between Python 2.x and 3.x is the bytes to Unicode shift, > and that is *not trivial*. Python 2.x tries very hard to make bytes and > strings interoperate even when doing so is the wrong thing to do. So > there is a lot of Python 2 code that is *broken* with respect to strings, > but *seems okay* so long as you only test it using pure ASCII. Python 3 > no longer tries to hide the difference, it forces you to confront the > fact that bytes and strings are not the same. To people raised on ASCII- > only programming standards, that's a huge paradigm shift, and a confusing > one. There's a lot to learn, a lot of pain if you don't learn it, and > there can be a lot of effort needed to migrate string code to Python 3.
Has anyone ever had the same "oh great, now I have to push everyone through a paradigm shift" feeling about anything else? The only one I can think of is shifting my whole family off Windows file sharing (just accessing files everywhere) onto wholesale use of source control (have a local copy, and push your changes). > (Depending on what your code actually does. It is remarkable just how > much string code you can write that works identically in 2.x and 3.x. > Basic string handling remains basic in both.) With PEP 461 (slated for 3.5), that's going to get even easier. Not only will a simple double-quoted string "do the right thing" on both platforms, but both b"binary" and u"unicode" will support the same percent-formatting as well. But you do have to limit your definition of "2.x"; a lot of that commonality is the result of deliberate design, and NOT just "oh hey look it works", which means that 2.4 and 3.4 are very different. I respect and do not envy those who have to support both RHEL and Arch... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
