Kevin Butler wrote:

M.-A. Lemburg wrote:

...

Kevin Butler wrote:

...

from unittest.assertions import *

...

That's bad style (at least for modules which don't only include constants). Why would you want to enable this ?

:-)

- In general, if you provide a submodule, users can do 'from unittest import assertions' or 'import unittest.assertions as test' or some such. Just having a grundle of top-level symbols in a module is less convenient than appropriate grouping into submodules.

- The Style Guide suggests prefixing methods that are intended for use with 'import *', and these functions are 'test*' or 'assert*'...

- For test code, I tend to be a bit more liberal with 'import *', because in general, test code is pretty clear about what it is exercising.

- The assertion methods are very independent of the other TestCase methods, and can be very useful for non-TestCase methods. This low coupling/high cohesion suggests organizing them together, but currently there's no convenient way to get at them separately. And since the methods really have little to do with an object instance, I find the 'self.assert*' construct distracting, although I like self.* in most cases.

I don't understand what you're after here, but if it's about making unittest a package and distributing the various bits in submodules of the package with the __init__.py file importing all of them... that's a way to approach the problem (if there is any ;-). I usually refactor modules that way as soon as they become too large to handle -- however, most of the times this is more an editing problem than a real need for a distributed design :-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/