On Thu, Mar 28, 2019 at 12:26 AM Steve Dower email@example.com wrote:
- Do we want everyone else to stop using it for their own purposes?
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.
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." 
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".