[Python-Dev] PEP 575: Unifying function/method classes
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
<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.
More information about the Python-Dev