On 27Mar2019 0324, Inada Naoki wrote:
On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki firstname.lastname@example.org wrote:
C, Rust, Java, Ruby, PHP, don't have PendingDeprecation. Programmers only need Deprecation. Why programmers need PendingDeprecation only in Python?
Any comments about this?
I want to document PendingDeprecationWarning is deprecated . May I merge the PR? Should I start poll on discuss.python.org?
There are two questions here:
1. Are we going to stop using it in CPython and the standard library? 2. Do we want everyone else to stop using it for their own purposes?
I think the first one is easy for us to answer (and personally, I don't care which way we go with it). However, deciding to stop using it ourselves is not the same as deprecating the class. So in this case, we would document that it is no longer used in CPython but is still available for other projects.
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.
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.
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.