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/
