[Python-Dev] Removing PendingDeprecationWarning

[Inada Naoki]

On Thu, Mar 28, 2019 at 12:26 AM Steve Dower <steve.dower at python.org> wrote:
>
[snip]
> 2. Do we want everyone else to stop using it for their own purposes?
[snip]
>
> The second question is harder to answer, and in the absence of input
> from those who are already using it (or the absence of evidence that
> nobody else is using it), the best we can do is evaluate how much of a
> maintenance burden the class is.
>
> In my opinion, it is a very low maintenance burden, and a very low
> cognitive burden on users, and so the cost of deprecating it on
> third-parties who are using it vastly outweighs the cost of leaving it
> alone.

As of my personal experience,  I used PendingDeprecationWarning
because it was convention, not because it is useful.

I didn't know "right way" to chose DeprecationWarning or
PendingDeprecationWarning.
So I need to survey convention in CPython.

I think I'm not only alone.  Many developers may pay costs:

1. Confused by two warning class.
2. Survey convention
3. Follow the convention (replace PendingDeprecationWarning to
    DeprecationWarning in N-1 release)

>
> If someone can show that either no third-parties are using it, or all
> those that do will probably never explicitly support Python 3.8 or
> later, or all those that do would prefer to stop using it, then I'll
> happily change my mind here. But right now, it seems like deprecating it
> will cause an unknown amount of churn for minimal benefit.
>

Even though "document only" deprecation?
I don't propose raising DeprecationWarning for use of PendingDeprecationWarning.

If you dislike document it as ".. deprecated:: 3.8", I'm OK to use "..
note::" directive.


> At most, I'd document it as "this will probably not survive to the next
> major change release, even though we aren't planning to do one yet"
> (much like the Py_UNICODE APIs). Ironically, PendingDeprecationWarning
> seems a pretty accurate way of indicating this state.
>
> Cheers,
> Steve

I think it is still confusing.  In case of Py_UNICODE, there are 10+ years until
"next major change release."  But it's not true for everytime.  If
there are only
two years until "next major version", we should absolutely use
DeprecationWarning.

And we used "document only deprecation" instead of PendingDeprecationWarning.
For example, array('u') have not raised PendingDeprecationWarning for long time.
Only document says "Deprecated since version 3.3, will be removed in
version 4.0." [1]

[1] https://docs.python.org/3/library/array.html

I prefer document only deprecation to PendingDeprecationWarning for somehting
"It will not removed in foreseeable future.  But it will probably
removed in the future."

Note that -Wd and testing tool enable both of PendingDeprecationWarning and
DeprecationWarning.  If we use PendingDeprecationWarning for them, it
will be too noisy.


I don't think it's worth enough to try "Make PendingDeprecationWarning
useful again!".
I want to document "PendingDeprecationWarning is not useful anymore".

-- 
Inada Naoki  <songofacandy at gmail.com>