R. David Murray <rdmur...@bitdance.com> added the comment: "Use it at your own risk" is always an option. Brett is saying that test.support docs need to make it clear that anyone using it is doing so at their own risk: it is for core development only and so we might change anything at any time without considering backward compatibility, and possibly even including incompatible changes in dot releases.[*] Given this, if you want your test suite to continue to pass without change across releases (barring bugs revealed by bug fixes, of course), then you should *not* use test.support even in your own test code.
Issue 8273 is saying, "Some of this stuff is generally useful and users want it, so we should put it in unittest". And then the standard library can used the improved unittest versions instead of the test.support ones. So the two issues are complimentary, not opposites :) [*] Others may disagree with me on this and perhaps we will not make incompatible changes in test.support in dot releases. But we *will* make incompatible changes in major releases without going through a deprecation process. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9255> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
