This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Thomas.Robitaille, martin.panter, mdk, ncoghlan, ned.deily, python-dev, serhiy.storchaka, vstinner
Date 2016-12-06.10:15:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1481019313.77.0.492692845037.issue28835@psf.upfronthosting.co.za>
In-reply-to
Content
I pushed a more complete version of my patch:

New changeset 726308cfe3b5 by Victor Stinner in branch '3.6':
catch_warnings() calls showwarning() if overriden
https://hg.python.org/cpython/rev/726308cfe3b5


I dislike pushing a different change than the reviewed change, but I was in a hurry for the Python 3.6.0 release :-/ Sorry about that.

Please double-check the pushed change!

(I used the wrong issue number, fixed in the following commit.)


The final change also fixes the bug reported by Martin:

Martin: "Actually, I found a regression. Looks like you also need to cancel any showwarning() function set by the user:"

I fixed it in catch_warnings() with these lines:

            # Reset showwarning() to the default implementation to make sure
            # that _showwarnmsg() calls _showwarnmsg_impl()
            self._module.showwarning = self._module._showwarning

It also added a new unit test for this scenario.


Serhiy Storchaka: "I don't understand why test_showwarnmsg_missing was added. Why deleting warnings._showwarnmsg should be supported?"

I don't know well the warnings module. The interactions between the C _warnings module and the Python warnings module are complex. I didn't want to break the backward compatibility, and *technically*, it is possible to delete warnings.showwarning() and warnings.warn("msg") still writes the message into stderr! So I decided to support this corner case, for the backward compatibility.

Code:
---
import warnings
warnings.warn("with showwarning")
del warnings.showwarning
warnings.warn("without showwarning")
---

Output on Python 3.5 (before my showarnmsg() changes):
---
x.py:2: UserWarning: with showwarning
  warnings.warn("with showwarning")
x.py:4: UserWarning: without showwarning
  warnings.warn("without showwarning")
---

Hum, but maybe we should decorate test_showwarnmsg_missing() with @cpython_only to announce that it's a side effect of the implementation, it's not part of the "Python specification".


Serhiy Storchaka: "I would rename _showwarning to _showwarning_orig for accenting it's purpose. It is used only for checking if showwarning was replaced by the user."

Sorry, I suck at naming things :-) Feel free to rename it (after the 3.6.0 release).


By the way, I'm still interested to make showwarnmsg() public in Python 3.7. IMO it's interesting to give access to the new source parameter to custom warning loggers. And it will allow to more easily extend warnings with new parameters (it was the whole purpose of the issue #26568).


I keep the issue open so someone can still review the pushed change.
History
Date User Action Args
2016-12-06 10:15:13vstinnersetrecipients: + vstinner, ncoghlan, ned.deily, python-dev, martin.panter, serhiy.storchaka, Thomas.Robitaille, mdk
2016-12-06 10:15:13vstinnersetmessageid: <1481019313.77.0.492692845037.issue28835@psf.upfronthosting.co.za>
2016-12-06 10:15:13vstinnerlinkissue28835 messages
2016-12-06 10:15:12vstinnercreate