On 04:36 pm, collinw at gmail.com wrote: >On 4/24/07, glyph at divmod.com <glyph at divmod.com> wrote: >>On 12:39 am, collinw at gmail.com wrote: >> >Fast and simple: I want all stdlib test cases to stop subclassing >> >unittest.TestCase and start subclassing test_support.TestCase. >> >> >So: any objections to making this change? >> >>Not an objection so much as a question - if these feature additions >>are >>generally interesting (and the ones you mentioned sounded like they >>are) why >>not simply add them to unittest.TestCase itself? After all, that is >>in the >>stdlib itself already. > >Because something like per-test refleak checking is completely useless >when testing pure-python code. Not everybody outside the stdlib is using the python unittest module to test pure-python code. >More generally, because not everything >that will be useful for the stdlib's test suite will be useful to >every single third-party test suite. I don't think that every single third-party test suite is using every single feature of the existing unittest module either, though. >It's also an issue of support: I >want the freedom to add functionality to the stdlib's test suite >without worrying about the impact on third-party unittest code. This makes sense to me, and I won't belabor the point. I just wanted to give a gentle reminder that if this functionality is useful to the standard library, it's likely that there are other libraries it would be useful to. Not putting it into the supported library right away makes sense, but if this functionality does prove useful, please consider making it standard. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20070424/37971f35/attachment.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4