Hi Ethan, Le ven. 18 oct. 2019 à 04:38, Ethan Furman <et...@stoneleaf.us> a écrit : > > 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.
I hesitated to use "core developers" instead of "developers" in the PEP, since CPython is not only maintained by "core developers". But it seems like it introduced some confusion. This paragraph is about CPython changes and core developers. Core developers love to drop legacy code :-) > How many versions back are we going to allow? I'm not sure that I correctly understand your question. Are you asking if I plan to only support Python 3.8, or if I plan to add support for Python 3.7 and older, in Python 3.9? If it is your question: I propose to add a partial Python 3.8 support in 3.9, then extend this backward compatiblity with Python 3.9 in Python 3.10, etc. If you are asking how many releases a backward compatibility will be supported, I would say that it should be discussed on a case by case basis. For example, let's say that Python 3.9 provides backward compatibility for collections ABC aliases and open() "U" mode. We may remove collections ABC aliases in Python 3.10, but keep open() "U" mode in Python 3.10 and only remove it from Python 3.11. Well, it's not different from what we already do with PendingDeprecationWarning, DeprecationWarning and the final feature removal. The deprecation duration is different for each deprecated function. > 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". Right, the PEP doesn't solve all compatibility issues. It proposes a compromise between "break all applications" (no bw compat) and "fix all applications" (full bw compat). It's a tradeoff depending on the CPython maintenance burden. > If they have to enable back-compatibility mode they still aren't getting the > latest features/performance. Why not? If you run your application on Python 3.9 and Python 3.9 is faster, your app will run faster, no? About latest features. Usually, Python modules support a range of Python versions, and are able to use newer functions when available. Let's say that MyApp application uses modules A and B. A is fully compatible with Python 3.9 and so is able to use latest cool Python features. The module B wasn't ported yet and so requests Python 3.8 backward compatibility. This doesn't remove Python 3.9 new features: they remain available. > Also, if the app isn't using these new features (even without > back-compatibility), how are they benefiting the user? If you ignore new features and better performance, there is still an advantage: being to run an old application unmodified, or at least to reduce the time needed to port it. Let's say that you have an old application which doesn't work unmodified on Python 3.9, but your system only provides Python 3.9. How do you run the application? Attempt "python3.9 -X compat_version=3.9 app.py". If you are lucky, the backward compatibility is enough to run the application unmodified. Great, isn't it? If not, at least the backward compatibility should reduce the number of changes needed to run the application. > > 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? I have no answer to this question. This problem isn't different from the current problem of introducing incompatible changes in Python on purpose. We can just hope that few projects will break. Or we still have the option of reverting the change if we were not lucky this time. It's all about luck currently :-) Right now, I have no idea how many projects are broken by the removal of collections ABC aliases. I'm confident that it's greater than 0, since we have to wait until pip is updated to stop using the deprecated alises. Even pip ignores DeprecationWarning... (In practice, it was a dependency which has been fixed long time ago, but there was no release...) > > 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. It's exactly the purpose of the PEP ;-) I tried to make it obvious in the "Redistribute the maintenance burden" section. If core developers want to break Python, fine! But they should help somehow to update projects written in Python, at least the most popular Python modules on PyPI. It's already the case, most of fixes to support the latest Python version are done by core developers. > > 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? I'm not sure if it's a real question or not. I only plan to add the compatibility with Python 3.8 and newer. Right now, I don't want to propose how many releases the compatibility of a specific function will be supported. If the PEP is accepted and implemented, I would prefer to see how it works in practice. Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/N757NNDLYC5T6VCWRDLS4LLUGPTGUEGW/ Code of Conduct: http://python.org/psf/codeofconduct/
