Python 2 to 3 conversion - embrace the pain

[Steven D'Aprano]

On Monday 16 March 2015 16:39, Chris Angelico wrote:

> On Mon, Mar 16, 2015 at 4:07 PM, Paul Rubin <no.email at nospam.invalid>
> wrote:
>> Python 2 is by now pretty solid and its users don't feel like beta
>> testers any more.  If you're saying using Python 3 by contrast means
>> "being first" and "reporting bugs", that basically translates to "stay
>> away from it except for experimentation".
> 
> Ah but it isn't Py3 that's all about being first - it's the latest
> version of some third-party module. This entire discussion came about
> because of non-stdlib modules - Python itself is quite mature. You
> might be the first to use XYZ with Py3, but you're not the first to
> use XYZ, nor the first to use Py3.

I think that's a distinction that makes no difference. Somebody has to be 
the first to migrate a large project to Python3+XYZ. The fact that others 
have successfully used Python2+XYZ or Python3+UVW or PHP+ABC is no comfort.

Let's not look at this through rose-tinted glasses. Big software projects 
are complicated, complex and even convoluted and major changes to libraries, 
languages or operating systems can break them. John ran into that, and bless 
him for reporting the bugs he found instead of keeping them secret so the 
next guy will run into them too.

It may, or may not, turn out that in hindsight there might have been better 
ways to manage the Python2-3 transaction. Let's be honest, a lot of the 
changes could have been introduced incrementally: with the possibly 
exception of the Unicode string business, I don't think anything *needed* a 
"flag day" cutover, they could have been handled by an incremental 
transition, e.g.:

2.5 add dict.viewkeys
2.6 noisily deprecate dict.keys and dict.iterkeys
2.7 remove dict.keys and dict.iterkeys and alias viewkeys to keys
2.8 deprecate viewkeys
2.9 remove viewkeys alias

Module renames could be handled via stub modules. Even Unicode strings could 
hypothetically have been added via a __future__ import.

BUT... would that actually have improved matters? I doubt it. It would have 
drawn the pain out much longer: every single new release will break 
*something*, and library authors will likely have a much harder job of 
supporting multiple versions.

I would have meant that users would be stuck with long periods of annoying 
deprecation warnings that they can't do anything about, and exponentially 
increased the pressure on the core devs to hold off removing deprecated 
features. What would have happened in practice probably would have been:

2.5 add dict.viewkeys
2.6 noisily deprecate dict.keys and dict.iterkeys
2.7 change deprecation to silent by default

and there it would stay, forever.

I suspect that without the discipline and bloody-mindedness to just say NO 
to requests to delay removal, Python would follow all those other languages 
that have an ever-increasing pile of cruft that can never be removed because 
it will break somebody's code. Design mistakes, obsolete features, 
misspellings, "it's like that for historical reasons", and other nasties.

Let's be frank: the average programmer has the aesthetic sense of a 
hyperactive weasel on LSD and wouldn't know a cleanly designed language if 
it fell from the sky and hit them on the head. Hence the popularity of PHP, 
Perl and C++. And the pointy-haired bosses holding the budget have even 
less, and zero care factor. "What do you mean the Python update broke our 
application *again*?"

With the Python3000 strategy, most user-space application developers can put 
off the pain until they are ready to deal with it, or put it off forever if 
they don't mind lacking an upgrade path beyond a certain point. Sometimes 
applications are just *finished*, there are no more features that need 
adding, no bugs that need fixing, and the only security feature you need is 
to lock the doors to the office when you leave at night. Those people have 
it easy: they can just get off the treadmill and ignore Python 3.x 
(2.7/2.6/2.5/2.4 ...) forever.



-- 
Steve