On Sat, Mar 23, 2019 at 2:26 AM Brett Cannon <email@example.com> 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.