Victor Stinner wrote: > Hi, > Le mer. 27 nov. 2019 à 19:40, Brett Cannon br...@python.org a écrit : > > What do people think of the idea of requiring all > > deprecations specifying a version that the feature will be removed in > > (which under our > > annual release cadence would be at least the third release from the start > > of the > > deprecation, hence the deprecation being public for 2 years)? And that we > > also follow > > through with that removal? > > Isn't it already the current unwritten deprecation process?
If it is we are not all doing a great job of following it. ;) > The common > case is to schedule the removal. Previously, it was common to wait 2 > releases before removing anything: pending deprecation in 3.6, > deprecation in 3.7, removal in 3.8. And this is why unwritten rule are bad: for me the rule was deprecation, then removal which was 1.5 years and will now be 2 years as we will be shifting to at least a two release deprecation cycle. > It means that developers are > warned during 2 releases: 3 years (I'm optimistic and consider that > developers pay attention to PendingDeprecationWarning). So deprecation > during 3 releases with the new release cadence would fit the previous > practice: 3 years ;-) > Are you suggesting to start with a PendingDeprecationWarning? No. > I recall > a debate about the value of this warning which is quiet by default, > whereas DeprecationWarning is now displayed in the __main__ module. > I'm not sure about enforcing the removal. Some APIs were deprecated, > but it was unsure if we really wanted to remove them. Or because we > had no idea how long it would take for developers to upgrade to the > new functions. Deprecations can always be extended, but leaving it perpetually open-ended seems like a bad idea to me. > For example, the C API for the old Unicode API using "Py_UNICODE*" > type is deprecated since Python 3.3 but there is no concrete plan to > remove it (just a vague "Python 4.0 removal" plan). > I deprecated the support for bytes filenames on Windows in Python 3.3, > but Steve Dower implemented his PEP 529 (use UTF-8 for bytes on > Windows) in Python 3.6 and so the deprecation warnings have been > simply removed! > I would suggest to schedule removal, but not require it too strongly ;-) > > Now I'm not suggesting it must be in > > three feature releases. A deprecation could be set to Python 4 (...) > > I know that it's an unpopular opinion, but I would strongly prefer > Python 4 to behave exactly as any another Python 3.x release in term > of deprecation. It will, it just might have a lot more code removed than a typical release. > If I exaggerate, I would prefer that Python 4.0 would > have less incompatible changes than the last Python 3.x release. Have "less incompatible changes" compared to what? By definition a shift in major version means there will be a difference. > I > hope that upgrading from Python 3 to Python 4 will be as smooth as > possible. I think we all do. And if people follow standard procedures to check for deprecations in the last release before Py4K then it will be like any other release for upgrading (at least in that regard). -Brett > Changing sys.version_info.major and "python4" program name > are already going to cause enough troubles. > Recently, I looked at all deprecation changes scheduled for removal in > Python 4.0. I removed these features in Python 3.9, especially for > features deprecated for more than 2 releases. See: > https://docs.python.org/dev/whatsnew/3.9.html#removed > For example, I removed the "U" mode of open() which was deprecated > since Python 3.4 and scheduled for removal in Python 4.0. > My plan is to revert these changes if too many users complain (see my > rejected PEP 606 and 608 :-D). > -- > I like to remove deprecated features at the beginning of a dev cycle > to get users feedback earlier. If they are removed late in the dev > cycle, there is a higher risk that a problematic incompatible change > goes through a 3.x.0 final release and so cannot be reverted anymore. > Victor > Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EWB4UM3MT23Y2FCVEVOUBIF7ZZJW35OS/ Code of Conduct: http://python.org/psf/codeofconduct/
