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
_______________________________________________
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/archive%40mail-archive.com
