[Python-Dev] PEP 575: Unifying function/method classes (original) (raw)

Eric V. Smith eric at trueblade.com
Thu May 3 07:58:49 EDT 2018

On 5/3/2018 6:22 AM, Jeroen Demeyer wrote:

On 2018-05-03 11:30, Victor Stinner wrote:

Please don't queue backward incompatible changes for Python 4.0. You should use the regular deprecation process. I don't really see how that can be done here. As Stefan said

The problem is that this change does not really fit into the deprecation cycle since there is no specific use case to warn about. The PEP proposes to change an implementation detail. It's really hard to determine at runtime whether code is relying on that implementation detail. We could insert a DeprecationWarning in some places, but those would mostly be false positives (a DeprecationWarning is shown but the code won't break). On top of that, there is no way to show a DeprecationWarning for code like "type(x) is foo".

Deprecating doesn't necessarily involve a DeprecationWarning, although if possible it should, of course. It could just be a documented deprecation. We've done this before, although I can't think of an example off the top of my head (which I realize is not exactly helpful).

"If you're doing a type check involving C functions, and you're doing it , change it to because we're going to deprecate the old way in version x.y". Of course this assumes both and can coexist for several versions, which itself might not be possible.

Eric

More information about the Python-Dev mailing list