On Mon, 16 Mar 2015 07:25 pm, Paul Rubin wrote: > Steven D'Aprano <steve+comp.lang.pyt...@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 -- https://mail.python.org/mailman/listinfo/python-list
