incorrect DeprecationWarning?

[Terry Reedy]

exarkun at twistedmatrix.com wrote:
> On 12:20 pm, alan.isaac at gmail.com wrote:

>> I think you are missing my point.
>> I understand it is just a DeprecationWarning.
>> But **why** should I receive a deprecation warning
>> when I am **not** using the deprecated practice?
>> Since I am **not** using the deprecated practice, the
>> warning is incorrect. (See the class definition above.)
>> And this incorrect warning affects a lot of people!
> 
> You are using the deprecated practice.  Attributes are not scoped to a 
> particular class.  There is only one "message" attribute on your 
> "MyError" instance.  It does not belong just to "MyError".  It does not 
> belong just to "Exception".  It does not belong just to "BaseException". 
> It is shared by all of them.  Because "BaseException" deprecates 
> instances of it having a "message" attribute, any instance of any 
> subclass of "BaseException" which uses this attribute will get the 
> deprecation warning.  Perhaps you weren't intending to use the "message" 
> attribute as "BaseException" was using it, but this doesn't matter. 
> There is only one "message" attribute, and "BaseException" already 
> claimed it, and then deprecated it.
>>
>> What anyone who is **not** using the deprecated practice
>> should expect in Python 2.6 is the Py3 behavior.  That is
>> not what we get: we get instead an incorrect deprecation
>> warning.
> 
> Possibly so, but there is no way for the runtime to know that you're not 
> trying to use the deprecated behavior.  All it can tell is that you're 
> using the deprecated attribute name.  Perhaps you can come up with a way 
> for it to differentiate between these two cases and contribute a patch, 
> though.

It is sometimes hard to warn exactly when appropriate and impossible for 
the default action to satisfy everyone. The developers are, of course, 
aware of this. That is why there is a mechanism to turn off particular 
warnings. Checkout the extremely flexible warnings module.

tjr