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 <old way>, change it to <new way> because we're going to deprecate the old way in version x.y". Of course this assumes both <old way> and <new way> can coexist for several versions, which itself might not be possible. Eric