Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> writes: >> better to make a fork of the language > You mean like Python 3?
No I mean like C to C++, or Lisp to Clojure, etc. Or if you prefer, C to OpenCL or maybe even C++ to Java or C to Go. If you're going to break old code, go big or go home ;-). > There are still people using Python 1.5, some in production, Yes, and Python 2 added stuff to Python 1.5 but it didn't break 1.5 programs (much), except for the ill-advised division change. Which by the way didn't introduce "true division"--rather, it replaced something mathematically meaningful with the weird computer vagary of floating point values. True division would have meant exact rationals, something that a really breaking change could have implemented. >> C code then and now used implementation-dependent hacks ... > People who really take backwards compatibility seriously make even their > undocumented behaviour backwards compatible, The more important such hacks are still supported by compilers, though sometimes you have to supply a command line option at compile time to keep the hack working. > the += operator was originally spelled =+ copying Ken Thompson's > earlier language "B". That was changed in 1976. That was before C was claiming to be mature and stable, so no prob. > Post-standardisation, here are a few other backwards incompatibilities: Hmm, maybe I'm behind the times. > - C99 introduced variable-length arrays, but C11 relegated it to an > optional feature which compilers are not required to support; You mean https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html ? They standardized that and then un-standardized it? Wow, that's interesting and probably not so wise. > - C99 changed the behaviour of floating point operations; They weren't very well-defined before and I bet compilers supply compatibility flags. > - C11 finally removed `gets`. I bet compiler libraries will keep supplying it forever though ;) > But the biggest problem is that C compilers vary (sometimes greatly) in what > subsets of the language they actually support. What works in compiler A may > not even compile on compiler B, let alone behave the same. Same as with CPython/Jython/IronPython/PyPy/MicroPython/Berp/??? >> I don't notice anyone wanting Python to change faster, in the sense of >> breaking existing code more often. > Are you on the python-ideas list? No, what's it like? How often does anyone make a serious proposal for more frequently breaking stuff? How often do they want to do it? > after almost a decade of development, the Python 3 ecosystem is now in > a fit state that people should prefer it for new projects. Given that Python 3 is a just few small tweaks added to Python 2, does the "almost a decade of development" show that something went badly wrong? Would uptake had been better if it either a) broke less stuff (maintaining more compatibility) b) broke more stuff (bringing greater benefits to switching)? I think it's plausible that the answer is yes to both. Also, ignoring whether people "should" prefer it for new projects: is there info available about whether they actually do? Someone named a shop that deals with a lot of internationalization and benefited from the unicode fixes, which is cool. I haven't been involved in any new python "projects" (meaning something with more planning and lifecycle expectations than it takes to write yet another throwaway script) in a while. If management called me in about a new project and asked whether to use Python 3, I'd have to consider it a complicated decision, especially if the target platform wasn't one of the widely supported ones: I did a fair amount of Python 2 on a custom embedded hardware box and would have to experiment to find out if Python 3 even runs on that thing. And if the idea is to break with the warty cruft of Python 2, I'd have to consider further-out alternatives like Go or Erlang, etc. > Anyone remember the big backwards incompatible changes made to Visual > Basic? How long did that take to settle down afterwards? No idea from me, I never used VB. -- https://mail.python.org/mailman/listinfo/python-list
