Python 2 to 3 conversion - embrace the pain

[Steven D'Aprano]

On Mon, 16 Mar 2015 07:25 pm, Paul Rubin wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>> 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...
> 
> Why did the changes have to be introduced at all?

For the same reason any improvement and functional update is introduced. To
make a better language.

If we were designing Python from scratch today, here are some of the changes
we would certainly make:


- only a single class system, not two independent ones (one of which 
  is buggy);
- Unicode strings by default;
- views and iterators in preference to lists;
- True and False as keywords, like None, not names that can be 
  redefined and shadowed;
- cleaner, more consistent, and more sensible naming conventions 
  for the standard library;
- Python is not C and / should perform true division, not integer
  division;
- some builtins of lesser use should be relegated to modules
- print as a statement was a mistake, it should be a function


etc. Python is a lesser language because of the accumulated cruft and design
mistakes from its 20-year history. If only we could turn back the clock and
redesign it with the benefit of hindsight, without worrying about backwards
compatibility!

Backwards compatibility limits your ability to improve the language and fix
mistakes and obsolete features. Whether you introduce those design fixes
all in one lump or spread out of twenty versions, you still have to break
backwards compatibility, or keep carrying the obsolete code 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.
> 
> The idea of "maturity" (an advertised feature of Python 2 back in the
> day) is that the pile of features is no longer growing so fast.  Right
> now I'm messing with some C code written in the 1980s and it still works
> fine.

Of course, not *all* C code written in the 1980s still works fine, but your
point is taken. C, like Fortran and Java, have an even stricter view of
backward compatibility than Python.

The downside of that is that learning and using C means you have to know and
learn a whole lot of ugly, dirty cruft, if only so you know what it means
when you see it in somebody else's code. Long after feature X has been made
obsolete, people still need to deal with it, *even if nobody uses it*.

And they will. We both know that no matter how bad and foolish a feature is,
no matter how loudly you tell people not to use this deprecated, insecure,
unsafe feature, until it is actually gone people will continue to write new
code using it.

You can't please everybody. Some people want Python to change even faster,
some want Python to stop changing so fast...


> I have a hard time imagining using Python 3 for anything.  Python 
> 2 has its cruft but it's familiar and comfortable, 

And that, I think, is the crux of the matter. Programmers, for all their
attraction to shiny new tech, are like cats in that they have a deep
distrust for anything too different. "Give me something completely new,
only exactly the same as the old one."


> and Python 3 gets 
> minimal benefit for most of the breakage that it did (possible exception
> of the Unicode changes).  It still has most of the same mistakes and
> warts.  If I wanted to get away from those, I'd use Go or Ocaml or
> Erlang or Haskell or Javascript (possibly through a compiler like
> Purescript) or whatever.

I find it hard to imagine anyone seriously preferring Javascript to Python
because Python has too many language warts. That's like somebody sitting
down to an entire Death By Chocolate cake for desert instead of a slice of
apple pie because apple pie has too many calories.

Nobody is stopping you from migrating all your code to Ocaml if you like.
(If you think migrating it from Python 2 to 3 is too hard, just try
migrating your code to another language.) And of course people *should*
learn new languages, that is a good thing.


> I'll see if I can remember what it was but I found some annoying
> incompatibility just a week or so ago that I don't think 2to3 would have
> caught, making me scared of Python 3 all over again.

If you remember, do tell.


-- 
Steven