[Python-Dev] Process to remove a Python feature (original) (raw)
Matthias Bussonnier bussonniermatthias at gmail.com
Fri May 4 15:08:06 EDT 2018
- Previous message (by thread): [Python-Dev] Process to remove a Python feature
- Next message (by thread): [Python-Dev] Process to remove a Python feature
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, 4 May 2018 at 11:49, Serhiy Storchaka <storchaka at gmail.com> wrote:
04.05.18 20:57, Matthias Bussonnier пише: > But when I hit a DeprecationWarning message there is one crucial piece of > information missing most of the time: Since which version number it's > deprecated > (and sometime since when the replacement is available could be good if > overlap > between functionality there was).
I think the information about since which version number it will be removed is more useful. Different cases need different deprecation periods. The more common the case, the longer deprecation period should be. Some recently added warnings contain this information.
Maybe to push people forward, but from experience it is hard to predict future, so saying when it will be remove is hard. When you want to remove it probably. Victor's first mail in this thread is a good example. The functionality was marked to be removed from 3.7, but I think it is likely too late now. You can always update, but I hate giving differing information between software version.
I'm curious about your use case for the version of removal, I usually don't care when it's going to be removed, I prefer since when the functionality is deprecated.
if pyversion < deprecated_version: old_stuff else: new_stuff
And I soon as my project drop deprecated_version, I remove the conditional. I do not try/except on purpose to be able to grep for when to remove the code.
Could you share you use case ? Of be ore detailed ?
We can also be more generic and say that if DeprecationWarning messages could contain timeline informations it would likely encourage the migration.
One related question is how much are DeprecationWarning messages stables between versions ? Would any update to many of these be accepted of refused because users might be filtering them ?
Matthias
Ideally any deprecated feature should have a replacement, and this replacement should be available in at least one version before adding the deprecation warning. X.Y: added a replacement X.Y+1: added a deprecation warning. Many users need to support only two recent versions and can move to using the replacement now. X.Y+3 (or X.Y+2): removed the deprecated feature. Versions older than X.Y should grew out of use at that moment.
Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/bussonniermatthias%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180504/3830b81a/attachment.html>
- Previous message (by thread): [Python-Dev] Process to remove a Python feature
- Next message (by thread): [Python-Dev] Process to remove a Python feature
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]