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
Hi,
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
Le mer. 27 nov. 2019 à 19:40, Brett Cannon
a écrit : 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-leave@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/DLHMA5BZ... Code of Conduct: http://python.org/psf/codeofconduct/