Silencing DeprecationWarning by default in Python 2.7 is silencing division warnings
I see two possible fixes for this. One is to not silence DeprecationWarning if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new subclass of DeprecationWarning called IntegerDivisionWarning and have that added to the warnings filter so that if it is triggered it is handled separately from what DeprecationWarning triggers. The former means that you might get more than you bargained for in terms of warnings as you are suddenly switching on all DeprecationWarnings on top of division warnings. The latter means that you now have to explicit care about IntegerDivisionWarning on top of DeprecationWarning (to minimize this I could have IntegerDivisionWarning added to the warnings filter only in the case of when Py_DivisionWarningFlag is set instead of blindly adding it). Thoughts? -Brett
2010/3/6 Brett Cannon <brett@python.org>:
I see two possible fixes for this. One is to not silence DeprecationWarning if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new subclass of DeprecationWarning called IntegerDivisionWarning and have that added to the warnings filter so that if it is triggered it is handled separately from what DeprecationWarning triggers. The former means that you might get more than you bargained for in terms of warnings as you are suddenly switching on all DeprecationWarnings on top of division warnings. The latter means that you now have to explicit care about IntegerDivisionWarning on top of DeprecationWarning (to minimize this I could have IntegerDivisionWarning added to the warnings filter only in the case of when Py_DivisionWarningFlag is set instead of blindly adding it). Thoughts?
How about just setting the warnings filter based on the integer division warning message? Might be a little brittle, but I don't much third party code is warning about classic division. -- Regards, Benjamin
Le Sat, 6 Mar 2010 11:43:20 -0800, Brett Cannon <brett@python.org> a écrit :
I see two possible fixes for this. One is to not silence DeprecationWarning if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new subclass of DeprecationWarning called IntegerDivisionWarning and have that added to the warnings filter so that if it is triggered it is handled separately from what DeprecationWarning triggers.
The latter would have my preference. Being able to discriminate between various classes of deprecations is good. Especially when what you want is to test for them :)
On Sat, Mar 6, 2010 at 12:43, Brett Cannon <brett@python.org> wrote:
I see two possible fixes for this. One is to not silence DeprecationWarning if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new subclass of DeprecationWarning called IntegerDivisionWarning and have that added to the warnings filter so that if it is triggered it is handled separately from what DeprecationWarning triggers. The former means that you might get more than you bargained for in terms of warnings as you are suddenly switching on all DeprecationWarnings on top of division warnings. The latter means that you now have to explicit care about IntegerDivisionWarning on top of DeprecationWarning (to minimize this I could have IntegerDivisionWarning added to the warnings filter only in the case of when Py_DivisionWarningFlag is set instead of blindly adding it). Thoughts? -Brett
Just to follow up on this with my current thinking, I am leaning towards having Py_DivisionWarningFlag disable the suppression of DeprecationWarning. Since the silencing is new in 2.7, people using -Q will not see any different semantics than they were with Python 2.6. Plus if they are bothering to be notified about division warnings they probably want to know about other warnings as well.
participants (3)
-
Antoine Pitrou -
Benjamin Peterson -
Brett Cannon