On Thu, Oct 17, 2019 at 7:39 PM Ethan Furman <et...@stoneleaf.us> wrote:
> 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 > -1 from me as well. > > > 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. > That was my immediate thought as well as you now have to test that code works in the stdlib for all potential version values to make sure all side-effects/ramifications are accounted for. And you already have sys.version_info for making sure you have a minimum version support for your code. Basically if people can't update yet then they simply can't update yet. Staying on an older version that they were already happy enough with to support shouldn't lead to a maintenance burden just to try and give them free performance perks at a cost to the core devs. -Brett > > > > 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~ > _______________________________________________ > 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/7D5IJJVWP3WY2YYSBOL6I6GRGLPZSPPN/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/NR7BBKYJXVJKZTGRDKLQCMJOU5XO745T/ Code of Conduct: http://python.org/psf/codeofconduct/
