In my opinion, the largest failure of Python 3 is that we failed to provide a smooth and *slow* transition from Python 2 and Python 3. It can be explained by the long list of backward incompatible changes.
My advice would be to restrict the number of backward incompatible changes per release, and always emit a warning (at runtime) in the previous release. For example, "async" and "await" have been marked as deprecated in Python 3.5, before becoming real keywords in Python 3.6. Then people complained that they didn't see the warning which is hidden by default, but that's another topic :-) (This issue is partially solved in Python 3.7 with Nick's PEP 565 and my -X dev option). I don't think that having Python X.Y which introduces backward incompatible changes is an issue by itself. We did it multiple times during the Python 3 cycle: my PEP 446 (non-inheritable file descriptors) and PEP 475 (retry syscalls interrupted by signals, PEP co-written with Charles-François Natali) introduced backward incompatible changes in Python 3.4 and 3.5. I am aware that they broke a few applications, but it was possible to manage these issues because each release only introduced a few backward incompatible changes. The main issue is the deprecation process. Should we provide tools to automatic conversion? Should we only document the deprecation, or also emit a warning at runtime? Should the warning be displayed by default? It's also a matter of collaboration with the Python community. For example, help major Python projects to handle these changes. Nobody wants to see pip broken by the next Python release for example. It seems like we are already working closely with pip, Cython and numpy, for example. IMHO queuing backward incompatible changes until Python 4 is a very bad idea. Start to break things early :-) But always follow the deprecation process. If my vote counts, Python 4.0 should just be the version following the previous Python 3.x release, as the Linux kernel is now doing (Linux 3 and Linux 4 are just regular release, they don't break everything.) Note: Another option is to never introduce backward incompatible changes, no? ;-) Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
