Martijn Faassen: The Call of Python 2.8

[Chris Angelico]

On Wed, Apr 16, 2014 at 12:51 PM, Steven D'Aprano
<steve+comp.lang.python at 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