[Python-Dev] Tweaking the stdlib test infrastructure

glyph at divmod.com glyph at divmod.com
Tue Apr 24 18:45:04 CEST 2007


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 


More information about the Python-Dev mailing list