'warnings' module changes still breaking Twisted, still looking for a fix
With the 2.6 final release impending, the Twisted community buildbot is still red, <http://bit.ly/zFymN>, but there only seems to be one real issue: the warn_explicit change. This seems like it could be a pretty minor bit of maintenance to clear up on our end, if Python provided the appropriate hook. The current solution we have in mind for this problem is to build our own warnings module <http://bit.ly/4F3Qr2>, but that is obviously inelegant. While we do want to experiment with our own features for deprecation, users of Twisted will (rightfully) expect our "assertWarns" to continue covering warnings produced by the Python 2.6 warnings system. The proposed solution to this problem seems to have been "warnings.catch_warnings()" <http://bugs.python.org/issue3602>, but it is insufficient for testing, since subsequent calls to "catch_warnings()" will not catch warnings suppressed by duplication suppression; without even getting into multiple tests testing the same code path, this breaks features like our 'trial' tool's "--until- failure" option, which runs a fixed group of tests repeatedly in an attempt to flush out buggy tests which have race conditions that cause them to fail intermittently. We thought we'd filed a ticket for this before, but searching around in the issue tracker hasn't come up with anything. JP Calderone has filed a new ticket for this problem: <http://bugs.python.org/issue3780> . Any chance this could be made into a release blocker? If this one issue were fixed, Python 2.6 would be the smallest disruption to Twisted since Python 2.0 :-).
On Thu, Sep 4, 2008 at 5:11 PM, <glyph@divmod.com> wrote:
With the 2.6 final release impending, the Twisted community buildbot is still red, <http://bit.ly/zFymN>, but there only seems to be one real issue: the warn_explicit change. This seems like it could be a pretty minor bit of maintenance to clear up on our end, if Python provided the appropriate hook.
The current solution we have in mind for this problem is to build our own warnings module <http://bit.ly/4F3Qr2>, but that is obviously inelegant. While we do want to experiment with our own features for deprecation, users of Twisted will (rightfully) expect our "assertWarns" to continue covering warnings produced by the Python 2.6 warnings system.
The proposed solution to this problem seems to have been "warnings.catch_warnings()" <http://bugs.python.org/issue3602>, but it is insufficient for testing, since subsequent calls to "catch_warnings()" will not catch warnings suppressed by duplication suppression; without even getting into multiple tests testing the same code path, this breaks features like our 'trial' tool's "--until- failure" option, which runs a fixed group of tests repeatedly in an attempt to flush out buggy tests which have race conditions that cause them to fail intermittently.
That's why catch_warning keeps track of the warnings filter too, so you can call warnings.simplefilter("always") within the context manager and the filter state will be restored.
We thought we'd filed a ticket for this before, but searching around in the issue tracker hasn't come up with anything. JP Calderone has filed a new ticket for this problem: <http://bugs.python.org/issue3780> .
Any chance this could be made into a release blocker? If this one issue were fixed, Python 2.6 would be the smallest disruption to Twisted since Python 2.0 :-). _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.c...
-- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."
On Thu, Sep 4, 2008 at 3:11 PM, <glyph@divmod.com> wrote:
With the 2.6 final release impending, the Twisted community buildbot is still red, <http://bit.ly/zFymN>, but there only seems to be one real issue: the warn_explicit change. This seems like it could be a pretty minor bit of maintenance to clear up on our end, if Python provided the appropriate hook.
The current solution we have in mind for this problem is to build our own warnings module <http://bit.ly/4F3Qr2>, but that is obviously inelegant.
And possibly unnecessary if you just want the old pure Python implementation for testing. It is not hard to force an import of warnings to use the pure Python version and totally ignore the C implementation. See test_warnings on how to pull that off. Then you can do your hack of overriding warn_explicit().
While we do want to experiment with our own features for deprecation, users of Twisted will (rightfully) expect our "assertWarns" to continue covering warnings produced by the Python 2.6 warnings system.
The proposed solution to this problem seems to have been "warnings.catch_warnings()" <http://bugs.python.org/issue3602>, but it is insufficient for testing, since subsequent calls to "catch_warnings()" will not catch warnings suppressed by duplication suppression; without even getting into multiple tests testing the same code path, this breaks features like our 'trial' tool's "--until- failure" option, which runs a fixed group of tests repeatedly in an attempt to flush out buggy tests which have race conditions that cause them to fail intermittently.
We thought we'd filed a ticket for this before, but searching around in the issue tracker hasn't come up with anything. JP Calderone has filed a new ticket for this problem: <http://bugs.python.org/issue3780> .
I am going to discuss technicalities on the issue. -Brett
On 10:35 pm, brett@python.org wrote:
It is not hard to force an import of warnings to use the pure Python version and totally ignore the C implementation. See test_warnings on how to pull that off. Then you can do your hack of overriding warn_explicit().
Benjamin Peterson's recommendation sounds like the winner (since we need to do *something* different in 2.6 anyway). Forcing the import leads to a bunch of import-ordering problems, since the testing tool itself wants to emit warnings, and self-test, and then it has to import the module _and_ set an attribute on the SUT module... Thanks for the tip, though.
participants (3)
-
Benjamin Peterson -
Brett Cannon -
glyph＠divmod.com