On Monday 16 March 2015 16:39, Chris Angelico wrote: > On Mon, Mar 16, 2015 at 4:07 PM, Paul Rubin <no.email@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 -- https://mail.python.org/mailman/listinfo/python-list
