Ezio Melotti <ezio.melo...@gmail.com> added the comment: I thought some more about this and I'm -0.5. The reasons are: * the patch introduces code/complexity in _baseAssertEqual and other places, using catch_warnings to change and restore the warning filters at every call; * this is needed only when Python is run with -b/-bb and that is quite uncommon (afaik); * even if this is not fixed, a test suite that passes all the tests without -b/-bb will most likely pass with -b/-bb[0]; * if there are failing tests with -b/-bb, it's usually possible to remove the -b/-bb and fix them before re-adding -bb[1];
[0]: the only exception I can think of is something like self.assertNotEqual(a_string, a_bytestring): this passes without -bb but fails with a BytesWarning with -bb. This tests is "wrong" though, because string are always not equal to bytestrings, regardless of their values. If one wants to make sure that a_string is not a bytestring, the correct way to do it is assertNotIsInstance(a_string, bytes). self.assertEqual(a_string, a_bytestring) fails already without -bb so, even if with -bb the traceback is less useful, it can/should be fixed without -b/-bb. To prove this further the whole Python test suite passes with -bb. [1]: that might indeed not be the case (e.g. with our buildbots is not easy to change flags), but I'm still not sure it's worth patching this just to have a better traceback in case of a test failure that accidentally involves bytes/string comparison on a Python running with -bb on an environment where changing the flags is not easy (i.e. a rather obscure corner case). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11887> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
