RetroSearch Browse

Thu May 3 07:58:49 EDT 2018 · https://mail.python.org/pipermail/python-dev/2018-May/153351.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-May/153351.html below:

[Python-Dev] PEP 575: Unifying function/method classes