On 10/17/2019 06:02 PM, Victor Stinner wrote:
I propose the following PEP to add sys.set_python_compat_version(version) to introduce a partial compatibility with Python 3.8 in the next Python 3.9 version.
-1
If possible, please try to read the whole PEP before replying.
Done. TL;DR Besides being a maintenance burden, and one more source of bugs, it will be a debugging nightmare -- especially if different levels of "back-compatibility" have been selected.
Rationale =========
The need to evolve frequently -----------------------------
To remain relevant and useful, Python has to evolve frequently. Some enhancements require incompatible changes. Any incompatible change can break an unknown number of Python projects. Developers can decide to not implement a feature because of that.
Is "developer" an app developer or a library developer? Either way, such developers are constrained by the lowest python version they support. How many versions back are we going to allow? If we don't support each and every breaking change then some application/library is going to be inoperable at the latest Python version, even with "back compatibility".
Users want to get the latest Python version to get new features and better performance. A few incompatible changes prevent them to use their applications on the latest Python version.
If they have to enable back-compatibility mode they still aren't getting the latest features/performance. Also, if the app isn't using these new features (even without back-compatibility), how are they benefiting the user?
Partial compatibility to minimize the Python maintenance burden ---------------------------------------------------------------
Backward compatibility code will be dropped at each Python release, on a case by case basis. Each compatibility function can be supported for a different number of Python releases depending on its maintenance cost and the estimated risk (number of broken projects) if it's removed.
How will we estimate this number? What's the minimum? Is that minimum number dependent on the user base of those projects? How do we estimate that?
Upgrade a project to a newer Python -----------------------------------
Without backward compatibility, all incompatible changes must be fixed at once, which can be a blocker issue. It is even worse when a project is upgraded to a newer Python which is separated by multiple releases from the old Python.
Postponing an upgrade only makes things worse: each skipped release adds more incompatible changes. The technical debt is only steadily increasing.
With backward compatibility, it becomes possible to upgrade Python increamentally in a project, without having to fix all issues at once.
Because the technical debt is now burdening Python instead.
The "all-or-nothing" is a showstopper to port large Python 2 code bases to Python 3. The list of incompatible changes between Python 2 and Python 3 is long, and it's getting longer at each Python 3.x release.
Are you saying we are going to add a Python2.7 compatibility layer? -- ~Ethan~