Mailman 3 Removing PendingDeprecationWarning - Python-Dev

Removing PendingDeprecationWarning

Inada Naoki

21 Mar 2019 21 Mar '19

9:41 p.m.

Hi, all. I'm thinking about removing PendingDeprecationWarning. (previous discussion: https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038) It was added "not be printed by default" version of DeprecationWarning. But DeprecationWarning is not printed by default now. We use PendingDeprecationWarning for N-2 release, and change it to DeprecationWarning for N-1 release. But this workflow seems not worth enough for now. I want to stop using PendingDeprecationWarning for new deprecation. More aggressively, I want to remove PendingDeprecationWarning class, and `PendingDeprecationWarning = DeprecationWarning` for backward compatibility. How do you think? May I do it in Python 3.8? -- Inada Naoki

Show replies by date

Victor Stinner

22 Mar 22 Mar

2:40 a.m.

Hi, I agree to make PendingDeprecationWarning an alias to DeprecationWarning. I never liked "PendingDeprecationWarning" name, it's way too long to type :-D Le ven. 22 mars 2019 à 03:45, Inada Naoki a écrit :

...

I want to stop using PendingDeprecationWarning for new deprecation.

I'm fine with that.

...

More aggressively, I want to remove PendingDeprecationWarning class, and `PendingDeprecationWarning = DeprecationWarning` for backward compatibility.

I'm not sure that I understand well. Do you want to remove the PendingDeprecationWarning builtin symbol, or just make it an alias to DeprecationWarning. I'm fine with "PendingDeprecationWarning = DeprecationWarning". IMHO your email title is misleading. You don't want to *remove* PendingDeprecationWarning, you only want to make it an alias to DeprecationWarning, right? In term of backward compatibility, it's very different :-) Victor

Inada Naoki

2:53 a.m.

On Fri, Mar 22, 2019 at 4:40 PM Victor Stinner wrote:

...

...
More aggressively, I want to remove PendingDeprecationWarning class, and `PendingDeprecationWarning = DeprecationWarning` for backward compatibility.

I'm not sure that I understand well. Do you want to remove the PendingDeprecationWarning builtin symbol, or just make it an alias to DeprecationWarning.

I'm fine with "PendingDeprecationWarning = DeprecationWarning".

I meant an alias in builtin.

...

IMHO your email title is misleading. You don't want to *remove* PendingDeprecationWarning, you only want to make it an alias to DeprecationWarning, right? In term of backward compatibility, it's very different :-)

Victor

Yes. It will be removed at some point, but not in near future. But when when backward compatibility can be kept by alias, we can be very lazy about removing it. We have `socket.error` for long time. Regards, -- Inada Naoki

Victor Stinner

3:06 a.m.

Le ven. 22 mars 2019 à 08:54, Inada Naoki a écrit :

...

Yes. It will be removed at some point, but not in near future.

But when when backward compatibility can be kept by alias, we can be very lazy about removing it.

Honestly, I don't see the point of removing PendingDeprecationWarning anytime soon. Practicality beats purity. Python is no longer about the purity of the language (we tried in Python 3.0, not sure that I want to want to do that again ;-)), but making it convenient to use for most people. Removing PendingDeprecationWarning doesn't bring any value to anyone. "PendingDeprecationWarning = DeprecationWarning" costs nothing in term of maintenance. If you care, I would suggest to invest time in static analyzers like pycodestyle, pylint, pyflakes, etc. Emit a warning with a low priority, and let users make their own choices.

...

We have `socket.error` for long time.

And it's perfectly fine, no? Victor -- Night gathers, and now my watch begins. It shall not end until my death.

Inada Naoki

3:16 a.m.

On Fri, Mar 22, 2019 at 5:06 PM Victor Stinner wrote:

...

Le ven. 22 mars 2019 à 08:54, Inada Naoki a écrit :

...
Yes. It will be removed at some point, but not in near future.

But when when backward compatibility can be kept by alias, we can be very lazy about removing it.

Honestly, I don't see the point of removing PendingDeprecationWarning anytime soon. Practicality beats purity.

I totally agree.

...

Removing PendingDeprecationWarning doesn't bring any value to anyone. "PendingDeprecationWarning = DeprecationWarning" costs nothing in term of maintenance.

If you care, I would suggest to invest time in static analyzers like pycodestyle, pylint, pyflakes, etc. Emit a warning with a low priority, and let users make their own choices.

Agree too.

...

...
We have `socket.error` for long time.

And it's perfectly fine, no?

Yes. Waiting 10+ years to remove aliases is fine. -- Inada Naoki

Victor Stinner

3:41 a.m.

Le ven. 22 mars 2019 à 09:16, Inada Naoki a écrit :

...

...
...
We have `socket.error` for long time.

And it's perfectly fine, no?

Yes. Waiting 10+ years to remove aliases is fine.

Sure. Let me elaborate my point of view on deprecation, since we are discussing it here (and I know that my opinion is not fully shared by all core devs, according to the bpo-35283 discussion, or maybe I'm wrong?) :-) Methods of threading.Thread changed their names to comply to PEP 8 coding style in Python 3: isAlive() has been renamed to is_alive(). The Threading.isAlive() method still exists in Python 3.8 and I think that it's ok. Removing it immediately would go against the best practice of writing a single code base working on Python 2 and Python3... I would be very annoyed to have to replace a simple "thread.isAlive()" call with something like "six.threading_is_alive(thread)" in my code, just because someone considered that the alias had to go away from the stdlib. Last December, Serhiy started to talk about removing isAlive(): "It is not even documented in Python 3, and can be removed in future." https://bugs.python.org/issue35283#msg330242 Antoine Pitrou suggested that "If it's not already deprecated, I'd say deprecate it first." And it has been done. I'm fine with deprecating things, since it doesn't prevent an application to be used. Use python3 -Wd (or python3 -X dev) to see these warnings if you want to be pedantic, but honestly, keeping the alias doesn't hurt anyone. Again, I mostly care about the maintenance cost: isAlive() is not documented, it's just 8 lines in threading.py and 2 lines in test_threading.py, and it's no like these lines require a lot of maintenance. IMHO the main metric should be to compare to cost to maintain such alias vs the pain affecting *all* Python users if we remove it. Right now, the maintenance cost is close to zero, whereas removing the alias would annoy a lot of people who will suddenly no longer be able to use their legacy code (written for Python 2 long time ago, but only ported to Python 3 recently). Getting a hard AttributeError exception is different than getting a silent DeprecationWarning :-) -- Wait, I'm not against removing things from Python. Don't tell anyone, but I *love* removing code, that's my greatest pleasure! IMHO Python is way too big and is expensive to maintain. But we should carefully discuss *each* feature removal, and plan properly a slow deprecation period to make sure that users had enough time to upgrade (and maybe extend it if needed). For Threading.isAlive(), IMHO the fact that Python 2 is still alive is simply a strong blocker issue. Let's discuss that that Python 2 usage will be closer to 0,1% than 50% :-) (Sorry, I don't think that it's really useful to discuss if Python 2 usage is more around 10% or 70%, that's not really the point: I made up "50%" :-)) Victor -- Night gathers, and now my watch begins. It shall not end until my death.

Steve Holden

4:30 a.m.

On Fri, Mar 22, 2019 at 8:43 AM Victor Stinner wrote:

...

Le ven. 22 mars 2019 à 09:16, Inada Naoki a écrit :

...
...
...
We have `socket.error` for long time.

And it's perfectly fine, no?

Yes. Waiting 10+ years to remove aliases is fine.

[...]

...

Right now, the maintenance cost is close to zero, whereas removing the alias would annoy a lot of people who will suddenly no longer be able to use their legacy code (written for Python 2 long time ago, but only ported to Python 3 recently). Getting a hard AttributeError exception is different than getting a silent DeprecationWarning :-)

Quite. Why expend the effort on a development that will cause unnecessary pain? Generally speaking, end-users will live their lives in blissful ignorance of [Pending]DeprecationWarning and should be allowed to do so. When a developer wants to migrate them to more recent versions of Python there's a chance that warnings will be enabled and examined, but it's by no means certain. I suspect the real value of the warnings is so that the dev team can shrug their shoulders when someone complains a feature has gone missing after ten years in deprecated status. This is the price of having them normally silent, which is certainly worth any trouble it causes by refusing to hassle innocent non-developers with warnings they can do nothing about.

Brett Cannon

12:25 p.m.

On Fri, Mar 22, 2019 at 12:41 AM Victor Stinner wrote:

...

Hi,

I agree to make PendingDeprecationWarning an alias to DeprecationWarning. I never liked "PendingDeprecationWarning" name, it's way too long to type :-D

Le ven. 22 mars 2019 à 03:45, Inada Naoki a écrit :

...
I want to stop using PendingDeprecationWarning for new deprecation.

I'm fine with that.

...
More aggressively, I want to remove PendingDeprecationWarning class, and `PendingDeprecationWarning = DeprecationWarning` for backward compatibility.

I'm not sure that I understand well. Do you want to remove the PendingDeprecationWarning builtin symbol, or just make it an alias to DeprecationWarning.

I'm fine with "PendingDeprecationWarning = DeprecationWarning".

We can't do that as it will break code. Think of code which is having warnings raise exceptions and that are purposefully catching PendingDeprecationWarning but not DeprecationWarning; this change would break that. These classes are part of the public API of the warnings module and so we shouldn't change semantics like that for people who have a specific use for those two different classes regardless of how the stdlib may choose to use them.

...

IMHO your email title is misleading. You don't want to *remove* PendingDeprecationWarning, you only want to make it an alias to DeprecationWarning, right? In term of backward compatibility, it's very different :-)

If you want to remove PendingDeprecationWarning that's a discussion we can obviously have (which I disagree with as shown in the discuss.python.org discussion), but I think aliasing is a non-starter.

Inada Naoki

12:37 p.m.

On Sat, Mar 23, 2019 at 2:26 AM Brett Cannon wrote:

...

We can't do that as it will break code. Think of code which is having warnings raise exceptions and that are purposefully catching PendingDeprecationWarning but not DeprecationWarning; this change would break that. These classes are part of the public API of the warnings module and so we shouldn't change semantics like that for people who have a specific use for those two different classes regardless of how the stdlib may choose to use them.

Didn't we already do it? socket.error was independent error class. It became alias of OSError from Python 3.3. There might be some small troubles. But it was small enough for Python minor versions, I think. -- Inada Naoki

Brett Cannon

1:01 p.m.

On Fri, Mar 22, 2019 at 10:37 AM Inada Naoki wrote:

...

On Sat, Mar 23, 2019 at 2:26 AM Brett Cannon wrote:

...
We can't do that as it will break code. Think of code which is having

warnings raise exceptions and that are purposefully catching PendingDeprecationWarning but not DeprecationWarning; this change would break that. These classes are part of the public API of the warnings module and so we shouldn't change semantics like that for people who have a specific use for those two different classes regardless of how the stdlib may choose to use them.

...
Didn't we already do it? socket.error was independent error class. It became alias of OSError from Python 3.3.

I would argue that makes more sense semantically than what you're proposing here as socket.error is a type of OSError while you're suddenly making PendingDeprecationWarning a "stronger" exception than it was.

...

There might be some small troubles. But it was small enough for Python minor versions, I think.

I don't think it's worth the cost to users. We can just choose to stop using it in the stdlib and not use PendingDeprecationWarning. And if people want to force others to define their own PendingDeprecationWarning by deprecating that's fine, but the aliasing where it could cause unintended exception swallowing for something related to breaking changes seems unnecessarily risky to me simply because we don't want to ask users to update their code in a backwards-compatible fashion.

Steve Dower

1:10 p.m.

On 22Mar2019 1101, Brett Cannon wrote:

...

On Fri, Mar 22, 2019 at 10:37 AM Inada Naoki mailto:songofacandy@gmail.com> wrote: There might be some small troubles. But it was small enough for Python minor versions, I think.

I don't think it's worth the cost to users. We can just choose to stop using it in the stdlib and not use PendingDeprecationWarning. And if people want to force others to define their own PendingDeprecationWarning by deprecating that's fine, but the aliasing where it could cause unintended exception swallowing for something related to breaking changes seems unnecessarily risky to me simply because we don't want to ask users to update their code in a backwards-compatible fashion.

What does it mean to put DeprecationWarning on PendingDeprecationWarning and then alias PendingDeprecationWarning to DeprecationWarning? "If the implementation is hard to explain, it's a bad idea." :) (FWIW, agree with Brett. We can simply stop using it ourselves without breaking anyone. Of all the things in the stdlib that are hard to maintain, this is nowhere near the top of the list.) Cheers, Steve

Inada Naoki

8:18 p.m.

On Sat, Mar 23, 2019 at 3:02 AM Brett Cannon wrote:

...

...
There might be some small troubles. But it was small enough for Python minor versions, I think.

I don't think it's worth the cost to users. We can just choose to stop using it in the stdlib and not use PendingDeprecationWarning. And if people want to force others to define their own PendingDeprecationWarning by deprecating that's fine, but the aliasing where it could cause unintended exception swallowing for something related to breaking changes seems unnecessarily risky to me simply because we don't want to ask users to update their code in a backwards-compatible fashion.

I still can't believe there are real world usage of PendingDeprecationWarning other than warnings.warn() and assertRaises(). But I'm OK to not removing actual class. Stop using it in stdlib reduces maintenance cost like this: https://github.com/python/cpython/pull/12494/files And deprecation in document reduces learning cost. People can skip reading and understanding document of PendingDeprecatedWarning. Keeping PendingDeprecationWarning class for several years is very low cost compared to these cost. Regards, -- Inada Naoki

Inada Naoki

9:10 p.m.

I created the PR to deprecate PendingDeprecationWarning only in document. https://github.com/python/cpython/pull/12505 On Sat, Mar 23, 2019 at 10:18 AM Inada Naoki wrote:

...

On Sat, Mar 23, 2019 at 3:02 AM Brett Cannon wrote:

...
...
There might be some small troubles. But it was small enough for Python minor versions, I think.

I don't think it's worth the cost to users. We can just choose to stop using it in the stdlib and not use PendingDeprecationWarning. And if people want to force others to define their own PendingDeprecationWarning by deprecating that's fine, but the aliasing where it could cause unintended exception swallowing for something related to breaking changes seems unnecessarily risky to me simply because we don't want to ask users to update their code in a backwards-compatible fashion.

I still can't believe there are real world usage of PendingDeprecationWarning other than warnings.warn() and assertRaises().

But I'm OK to not removing actual class.

Stop using it in stdlib reduces maintenance cost like this: https://github.com/python/cpython/pull/12494/files

And deprecation in document reduces learning cost. People can skip reading and understanding document of PendingDeprecatedWarning.

Keeping PendingDeprecationWarning class for several years is very low cost compared to these cost.

Regards, -- Inada Naoki

-- Inada Naoki

Brett Cannon

23 Mar 23 Mar

6:07 p.m.

On Fri, Mar 22, 2019 at 6:19 PM Inada Naoki wrote:

...

On Sat, Mar 23, 2019 at 3:02 AM Brett Cannon wrote:

...
...
There might be some small troubles. But it was small enough for Python minor versions, I think.

I don't think it's worth the cost to users. We can just choose to stop

using it in the stdlib and not use PendingDeprecationWarning. And if people want to force others to define their own PendingDeprecationWarning by deprecating that's fine, but the aliasing where it could cause unintended exception swallowing for something related to breaking changes seems unnecessarily risky to me simply because we don't want to ask users to update their code in a backwards-compatible fashion.

I still can't believe there are real world usage of PendingDeprecationWarning other than warnings.warn() and assertRaises().

I've made the same mistake of assuming something that made no sense to me wouldn't make sense to anyone else and I have been proven wrong nearly every time. ;) -Brett

...

But I'm OK to not removing actual class.

Stop using it in stdlib reduces maintenance cost like this: https://github.com/python/cpython/pull/12494/files

And deprecation in document reduces learning cost. People can skip reading and understanding document of PendingDeprecatedWarning.

Keeping PendingDeprecationWarning class for several years is very low cost compared to these cost.

Regards, -- Inada Naoki

Inada Naoki

8:51 p.m.

On Sun, Mar 24, 2019 at 8:07 AM Brett Cannon wrote:

...

I've made the same mistake of assuming something that made no sense to me wouldn't make sense to anyone else and I have been proven wrong nearly every time. ;)

-Brett

And beta and RC phase can be used to detect such breakage. When no real world pain is assumed, we can chose simple solution. Then, if real world pain is found, we can move to more complicated, but backward compatible way. Of course, keeping PendingDeprecatedWarning is not complicated way in this time. So I don't push the removal. It was just an idea. -- Inada Naoki

Serhiy Storchaka

22 Mar 22 Mar

5:33 a.m.

22.03.19 04:41, Inada Naoki пише:

...

I'm thinking about removing PendingDeprecationWarning. (previous discussion: https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038)

It was added "not be printed by default" version of DeprecationWarning. But DeprecationWarning is not printed by default now.

We use PendingDeprecationWarning for N-2 release, and change it to DeprecationWarning for N-1 release. But this workflow seems not worth enough for now.

I want to stop using PendingDeprecationWarning for new deprecation.

More aggressively, I want to remove PendingDeprecationWarning class, and `PendingDeprecationWarning = DeprecationWarning` for backward compatibility.

How do you think? May I do it in Python 3.8?

What is wrong with PendingDeprecationWarning? What problem do you want to solve at the cost of removing this feature? Now, when DeprecationWarning is displayed by default in the interactive session, in __main__ and in development runtime mode (and this list can be extended), PendingDeprecationWarning is useful again. Even if the interpreter itself would not use it, it is used in third-party projects.

Jeroen Demeyer

5:51 a.m.

On 2019-03-22 11:33, Serhiy Storchaka wrote:

...

What is wrong with PendingDeprecationWarning?

It serves the same purpose as DeprecationWarning: it indicates that a feature is planned to be removed in the future. There is no point in having two warnings with exactly the same meaning.

...

What problem do you want to solve at the cost of removing this feature?

1. Typically, a PendingDeprecationWarning is meant to be promoted to a DeprecationWarning in some future release. It takes a minor effort to do that and it may be forgotten. It's just simpler to use DeprecationWarning from the start. 2. Whenever somebody wants to deprecate something, that person has to decide between the two. That's just more complicated than it needs to be. And I can easily ask the converse question: what problem do you want to solve by including that feature?

Serhiy Storchaka

6:49 a.m.

22.03.19 12:51, Jeroen Demeyer пише:

...

On 2019-03-22 11:33, Serhiy Storchaka wrote:

...
What is wrong with PendingDeprecationWarning?

It serves the same purpose as DeprecationWarning: it indicates that a feature is planned to be removed in the future. There is no point in having two warnings with exactly the same meaning.

But does not flood the end user with warnings, so you can continue to use deprecated features for a while. This makes the transition more smooth.

...

...
What problem do you want to solve at the cost of removing this feature?

1. Typically, a PendingDeprecationWarning is meant to be promoted to a DeprecationWarning in some future release. It takes a minor effort to do that and it may be forgotten. It's just simpler to use DeprecationWarning from the start.

What is wrong if it be forgotten? Simpler does not mean better.

...

2. Whenever somebody wants to deprecate something, that person has to decide between the two. That's just more complicated than it needs to be.

If he want to provide a more smooth transition way, he should start with a PendingDeprecationWarning. Otherwise he can use a DeprecationWarning.

...

And I can easily ask the converse question: what problem do you want to solve by including that feature?

It allowed to mark a feature deprecated for developers without harming the end users.

Inada Naoki

6:52 a.m.

On Fri, Mar 22, 2019 at 8:49 PM Serhiy Storchaka wrote:

...

...
And I can easily ask the converse question: what problem do you want to solve by including that feature?

It allowed to mark a feature deprecated for developers without harming the end users.

Both of DeprecationWarning and PendingDeprecationWarning are not for end users. Only FutureWarning is for end users now. -- Inada Naoki

Inada Naoki

6:23 a.m.

On Fri, Mar 22, 2019 at 7:36 PM Serhiy Storchaka wrote:

...

...
How do you think? May I do it in Python 3.8?

What is wrong with PendingDeprecationWarning? What problem do you want to solve at the cost of removing this feature?

The main problem is complexity. In other words, learning cost. All Python library developer would like to know how to deprecate something. They will understand "deprecated" means "will be removed in the future version" easily. Then, "will be deprecated" [1] is easy to understand? "will be (will be removed)" is very curious. To understand what PendingDeprecationWarning is for, they need to learn history which is not documented in clearly. [1]: https://docs.python.org/3/library/exceptions.html#PendingDeprecationWarning If we deprecate PendingDeprecationWarning, people don't have to understand what it is for.

...

Now, when DeprecationWarning is displayed by default in the interactive session, in __main__ and in development runtime mode (and this list can be extended), PendingDeprecationWarning is useful again. Even if the interpreter itself would not use it, it is used in third-party projects.

This benefits seems too small compared to the learning cost. -- Inada Naoki

Serhiy Storchaka

7:01 a.m.

22.03.19 13:23, Inada Naoki пише:

...

On Fri, Mar 22, 2019 at 7:36 PM Serhiy Storchaka wrote:

...
What is wrong with PendingDeprecationWarning? What problem do you want to solve at the cost of removing this feature?

The main problem is complexity. In other words, learning cost.

Do you have evidences that many people have troubles with learning PendingDeprecationWarning?

...

All Python library developer would like to know how to deprecate something.

They will understand "deprecated" means "will be removed in the future version" easily.

Then, "will be deprecated" [1] is easy to understand? "will be (will be removed)" is very curious. To understand what PendingDeprecationWarning is for, they need to learn history which is not documented in clearly.

[1]: https://docs.python.org/3/library/exceptions.html#PendingDeprecationWarning

Perhaps the better solution of this is to improve the documentation. PendingDeprecationWarning means that you still can use the deprecated feature. When we deprecate some feature, we should provide an alternate way to solve the same problem. And it is better if that way is available in few previous Python versions. So the developer which need to support several Python versions could just switch to a modern way. This is how we do, or at least must to do, to be polite with Python programmers. PendingDeprecationWarning just give us time to add an alternate way if it is not available yet, and give Python programmers time to adapt their code.

...

If we deprecate PendingDeprecationWarning, people don't have to understand what it is for.

...
Now, when DeprecationWarning is displayed by default in the interactive session, in __main__ and in development runtime mode (and this list can be extended), PendingDeprecationWarning is useful again. Even if the interpreter itself would not use it, it is used in third-party projects.

This benefits seems too small compared to the learning cost.

I do not think so.

Victor Stinner

11:08 a.m.

Le ven. 22 mars 2019 à 13:05, Serhiy Storchaka a écrit :

...

...
The main problem is complexity. In other words, learning cost.

Do you have evidences that many people have troubles with learning PendingDeprecationWarning?

I have no idea when I should use PendingDeprecationWarning rather than DeprecationWarning. For example, let's say that we deprecate a feature in Python N with an open question of remove it from Python N+1 or N+2. Should I started with PendingDeprecationWarning? The following discussion mentioned that many deprecated features are not removed just because everybody forgot to remove it: https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038 And I consider that it's perfectly fine to not have a strict plan to remove a feature as part of a deprecation. The usage of a deprecated feature can evolve. There are a few exceptions of deprecated features which were only modified to remove the deprecation, rather than removing the feature, because we decided that the fetaure must stay. Python language is living, its usage is changing frequently. About showing warnings: I never ever used a specific filter to only hide PendingDeprecationWarning but show DeprecationWarning. When I want to fix warnings, I want to fix all of them, pending or not. I would like to prepare a project for all future Python versions, not only fix DeprecationWarning. "python3 -X dev", "python3 -Wd" and python3 compiled in debug modes all show DeprecationWarning *and* PendingDeprecationWarning. The granularity no longer matters. It was useful to have PendingDeprecationWarning when it was hidden by default, whereas DeprecationWarning warnings were displayed by default. But now both are hidden by default. Well, maybe read the whole previous discussion for the full rationale: https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038

...

Perhaps the better solution of this is to improve the documentation.

PendingDeprecationWarning means that you still can use the deprecated feature.

Honestly, I'm not really excited by using a feature that is tagged to be deprecated in the future... IMHO the difference between PendingDeprecationWarning and DeprecationWarning is too subtle to be useful in practice.

...

PendingDeprecationWarning just give us time to add an alternate way if it is not available yet, and give Python programmers time to adapt their code.

Do you have some examples? Victor -- Night gathers, and now my watch begins. It shall not end until my death.

Nick Coghlan

24 Mar 24 Mar

6:57 a.m.

On Fri, 22 Mar 2019 at 12:45, Inada Naoki wrote:

...

Hi, all.

I'm thinking about removing PendingDeprecationWarning. (previous discussion: https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038)

It was added "not be printed by default" version of DeprecationWarning. But DeprecationWarning is not printed by default now.

No, this was covered in PEP 565, and PendingDeprecationWarning was explicitly kept as a way of opting out of the revised semantics of DeprecationWarning. In Python 3.7 and above, the semantics are: * PendingDeprecationWarning: never shown by default * DeprecationWarning: shown by default in the __main__ module * FutureWarning: shown by default everywhere PEP section: https://www.python.org/dev/peps/pep-0565/#additional-use-case-for-futurewarn... The documentation was also updated to match: * https://docs.python.org/3/library/warnings.html#warning-categories * https://docs.python.org/3/library/exceptions.html#warnings Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Inada Naoki

11:39 p.m.

On Sun, Mar 24, 2019 at 8:57 PM Nick Coghlan wrote:

...

...
It was added "not be printed by default" version of DeprecationWarning. But DeprecationWarning is not printed by default now.

No, this was covered in PEP 565, and PendingDeprecationWarning was explicitly kept as a way of opting out of the revised semantics of DeprecationWarning.

I know PEP 565. And I don't think difference between PendingDeprecationWarning and DeprecationWarning is still too small to have two categories. For example, $ cat foo.py import warnings def foo(): warnings.warn("foo", DeprecationWarning) $ python3 Python 3.7.2 (default, Feb 12 2019, 08:15:36) [Clang 10.0.0 (clang-1000.11.45.5)] on darwin Type "help", "copyright", "credits" or "license" for more information.

...

...
...
import foo foo.foo()

(no warning shown)

$ cat >bar.py import foo foo.foo() $ python3 bar.py (no warning shown) I can't find I'm using deprecated APIs even when I'm using REPL. When people want to check use of deprecated APIs, they need to use -X dev or -Wd option anyway. We have many ways to deprecation: * Document only deprecation (no warning) -- no actual removal is planned. * FutureWarning -- to warn end users. * DeprecationWarning -- to warn Python developers. * PendingDeprecationWarning -- to warn Python developers. -- Inada Naoki

Nick Coghlan

25 Mar 25 Mar

6:53 a.m.

On Mon, 25 Mar 2019 at 14:39, Inada Naoki wrote:

...

We have many ways to deprecation:

* Document only deprecation (no warning) -- no actual removal is planned. * FutureWarning -- to warn end users. * DeprecationWarning -- to warn Python developers. * PendingDeprecationWarning -- to warn Python developers.

The key difference between the last two: * DeprecationWarning: the decision has already been made, you have little chance of getting the deprecation reversed * PendingDeprecationWarning: full deprecation is being considered, now is the time to get in touch if you'd like to avoid full deprecation Hence the last one only showing up to those folks that are running automated tests or otherwise enabling all warnings. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Antoine Pitrou

7:51 a.m.

On Mon, 25 Mar 2019 21:53:07 +1000 Nick Coghlan wrote:

...

On Mon, 25 Mar 2019 at 14:39, Inada Naoki wrote:

...
We have many ways to deprecation:

* Document only deprecation (no warning) -- no actual removal is planned. * FutureWarning -- to warn end users. * DeprecationWarning -- to warn Python developers. * PendingDeprecationWarning -- to warn Python developers.

The key difference between the last two:

* DeprecationWarning: the decision has already been made, you have little chance of getting the deprecation reversed * PendingDeprecationWarning: full deprecation is being considered, now is the time to get in touch if you'd like to avoid full deprecation

Are people actually aware of this difference? Personally I am (was) not. Regards Antoine.

Inada Naoki

8:11 a.m.

On Mon, Mar 25, 2019 at 8:53 PM Nick Coghlan wrote:

...

On Mon, 25 Mar 2019 at 14:39, Inada Naoki wrote:

...
We have many ways to deprecation:

* Document only deprecation (no warning) -- no actual removal is planned. * FutureWarning -- to warn end users. * DeprecationWarning -- to warn Python developers. * PendingDeprecationWarning -- to warn Python developers.

The key difference between the last two:

* DeprecationWarning: the decision has already been made, you have little chance of getting the deprecation reversed * PendingDeprecationWarning: full deprecation is being considered, now is the time to get in touch if you'd like to avoid full deprecation

Hence the last one only showing up to those folks that are running automated tests or otherwise enabling all warnings.

Cheers, Nick.

PendingDeprecationWarning was added when DeprecationWarning is shown by default and it is too noisy for end users. After Python 2.7 and 3.2, there are no difference between two classes. PEP 565 tried to introduce difference again. But the difference is still too little. I have not seen DeprecationWarning enabled by PEP 565. I see both warning when I'm using PYTHONWARNINGS=default or -Wd, or running test. I don't think it's worth enough to try giving meaning to PendingDeprecationWarning again. C, Rust, Java, Ruby, PHP, don't have PendingDeprecation. Programmers only need Deprecation. Why programmers need PendingDeprecation only in Python? If it is really important, I think we need easy option to enable only DeprecationWarning. It must be as easy as -Wd. -- Inada Naoki

Inada Naoki

27 Mar 27 Mar

5:24 a.m.

On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki 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 [1]. May I merge the PR? Should I start poll on discuss.python.org? [1]: https://github.com/python/cpython/pull/12505/files -- Inada Naoki

Steve Dower

10:26 a.m.

On 27Mar2019 0324, Inada Naoki wrote:

...

On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki 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 [1]. May I merge the PR? Should I start poll on discuss.python.org?

[1]: https://github.com/python/cpython/pull/12505/files

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. Cheers, Steve

Paul Moore

10:45 a.m.

On Wed, 27 Mar 2019 at 15:29, Steve Dower wrote:

...

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.

FWIW, https://searchcode.com/?q=PendingDeprecationWarning&lan=19 says there are about 6.786 results. I haven't looked extensively, but Django seems to be in there. The msgpack library that is vendored by pip (ironically, maintained by INADA-San) also uses it in one place. Personally, I don't think deprecation is worth the disruption. Paul

Inada Naoki

9:27 p.m.

On Thu, Mar 28, 2019 at 12:26 AM Steve Dower 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

Nick Coghlan

30 Mar 30 Mar

5:31 a.m.

On Thu, 28 Mar 2019 at 12:31, Inada Naoki wrote:

...

I didn't know "right way" to chose DeprecationWarning or PendingDeprecationWarning.

That's just a documentation fix: "If you're not sure whether to use DeprecationWarning or PendingDeprecationWarning, use DeprecationWarning". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Inada Naoki

1 Apr 1 Apr

3:26 a.m.

On Sat, Mar 30, 2019 at 7:31 PM Nick Coghlan wrote:

...

That's just a documentation fix: "If you're not sure whether to use DeprecationWarning or PendingDeprecationWarning, use DeprecationWarning".

Current proposed patch is: """ .. note:: PendingDeprecationWarning was introduced as an "ignored by default" version of DeprecationWarning. But :exc:`DeprecationWarning` is also ignored by default since Python 2.7 and 3.2. There is not much difference between PendingDeprecationWarning and DeprecationWarning nowadays. DeprecationWarning is recommended in general. """ https://github.com/python/cpython/pull/12505/files#diff-4d7187c7266c3f79727d... -- Inada Naoki

Brett Cannon

27 Mar 27 Mar

11:58 a.m.

On Wed, Mar 27, 2019 at 3:26 AM Inada Naoki wrote:

...

On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki 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?

You know my views on this. :) Leave it and we start to consistently use if for deprecations that are more than a release away from removal (and for those not reading discuss.python.org, I proposed over there introducing a warnings._deprecate() function for the stdlib which will do the right thing based on sys.version_info() and the stated start/end for the deprecation). It might also make sense to hold off on anything official until we decide on something like PEP 387 and how we want to officially communicate deprecations. -Brett

...

I want to document PendingDeprecationWarning is deprecated [1]. May I merge the PR? Should I start poll on discuss.python.org?

[1]: https://github.com/python/cpython/pull/12505/files

-- Inada Naoki _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org

Nick Coghlan

30 Mar 30 Mar

5:28 a.m.

On Wed, 27 Mar 2019 at 20:29, Inada Naoki wrote:

...

On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki 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 [1]. May I merge the PR? Should I start poll on discuss.python.org?

No, just leave it alone, as removing it is pointless churn for no good reason. If folks don't want to use it, they don't have to use it. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

1852

Age (days ago)

1862

Last active (days ago)

List overview

Download

34 comments

10 participants

participants (10)

Antoine Pitrou
Brett Cannon
Inada Naoki
Jeroen Demeyer
Nick Coghlan
Paul Moore
Serhiy Storchaka
Steve Dower
Steve Holden
Victor Stinner

Removing PendingDeprecationWarning

tags

participants (10)