Victor Stinner wrote: > Isn't it already the current unwritten deprecation process?
Personally, I don't think we should rely on an unwritten process for something as important and potentially breaking as a deprecation process. Regardless of the outcome of this discussion, I think we should try to fully write out the process in the devguide; while still providing some amount of flexibility. Victor Stinner wrote: > 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. ... > I would suggest to schedule removal, but not require it too strongly ;-) Would it be reasonable to require an minimum amount of versions to be specified (such as n versions ahead), but provide flexibility in terms to delaying the removal, as needed? IMO, it would be more convenient for users to have a "minimum removal" version in mind, rather than an unscheduled deprecation that could have a version+2 (deprecation and removal in 2 versions) assigned at any point in time. This can be difficult sometimes when we're not sure what n versions from now will actually be called (such as with 3.10 and 4.0), but I don't think it would be an issue to state something like this: "func() has been deprecated, and will be removed in no sooner than 4 versions after 3.9" instead of: "func() has been deprecated, and will be removed in 3.13" for long term deprecations. By "long term", I mean more than two versions. Victor Stinner wrote: > 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. If I exaggerate, I would prefer that Python 4.0 would > have *less* incompatible changes than the last Python 3.x release. My understanding was that we were specifically waiting on considering a Python 4.0 until there were major enough improvements/changes (such as the "GILectomy", for example) to justify some degree of incompatibility. If it would behave exactly the same as a standard 3.x release in terms to incompatible changes (or have less), what would be the purpose of making a major version change in the first place? I don't see an issue with indefinitely continuing the 3.x line in the meantime. Victor Stinner wrote: > 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. I agree, the earlier a deprecation occurs in a given release cycle, the easier it is for users to provide feedback and then potentially prepare for the change. Perhaps we could establish some form of guideline, for example: "When possible, the removal of previously deprecated features should occur as early as possible in a version's dev cycle, preferably during the alpha phases. This provides users more time to provide feedback and plan for the potential removal". On Fri, Dec 6, 2019 at 10:58 AM Victor Stinner <vstin...@python.org> 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? The common > case is to schedule the removal. Previously, it was common to wait 2 > releases before removing anything: pending deprecatation in 3.6, > deprecation in 3.7, removal in 3.8. 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? 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. > > 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. If I exaggerate, I would prefer that Python 4.0 would > have *less* incompatible changes than the last Python 3.x release. I > hope that upgrading from Python 3 to Python 4 will be as smooth as > possible. 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/DLHMA5BZAHJ5QKWJKK6WX33R5EJWN5G5/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/2OS6MO46GKJKOTDF6VM3PFS464OW53VU/ Code of Conduct: http://python.org/psf/codeofconduct/
