[Python-Dev] Process to remove a Python feature

[Brett Cannon]

On Fri, 4 May 2018 at 12:09 Matthias Bussonnier <
bussonniermatthias at gmail.com> wrote:

> 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.
>

So there is actually an opportunity here to programmatically help prevent
missing a removal. If we attach a version number for when a
DeprecationWarning is expected to go away due to removal we can then have
the warning itself raise a warning that while the DeprecationWarning was
supposed to be gone by e.g. 3.7, it's still being raised. The drawback to
this is it will make the first cut-over to a newer version of Python a bit
more painful, but as long as warnings don't raise exceptions it should just
be a noisy.


>
> 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.
>

The other way to look at that is:

if pyversion < replacement:
  old_stuff
else:
  new_stuff

In which case you don't care about when the deprecation happened, just when
it's replacement was introduced (which Serhiy suggested being a version
before the deprecation is added).


> 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 ?
>

Same as any other exception; typically left alone unless there's a better
way to phrase things (IOW don't parse the message ;) .

So at this point there are basically two threads going on here.

One is an official deprecation policy. E.g. X.Y something happens, X.Y+1
something else happens, etc.

The other one is how to make what gets deprecated more discoverable. E.g.
an informational PEP that tracks what's planned, warnings having more
metadata, etc.

Both of these things seem independent, although one of them will require a
PEP while the other just takes some work (I leave it as an exercise for the
reader to figure out which one is which ;) .

-Brett


> 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
>>
> _______________________________________________
> 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/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180504/6b13afd2/attachment-0001.html>