On Sun, Jan 27, 2013 at 3:13 PM, Ezio Melotti <report@bugs.python.org>wrote:

>
> Ezio Melotti added the comment:
>
> Note that while this works for the simple case, it doesn't work whenever
> you need additional tests or attributes that are specific for one of the
> two classes,

Sure it does. The modules are simply attributes on the PEP399Test instance,
so you can still access the modules just as easily in test classes that
don't need to be tested with both possible modules.

or when you have additional base classes.

That can easily be solved with the argument to create_test_cases(), e.g.
``def create_test_cases(*bases_classes): ... class PyTest(*(base_classes +
[unittest.TestCase])): pass``.

>  This is also not so uncommon.  I think the skip on the accelerated
> version might not be necessary in some situations.
>

Then don't use this approach. It doesn't have to apply to every single test
class in a module. It just needs to help in the simple case.

>
> IOW we have to trade between compactness, flexibility, and readability,
> and trying to improve one side will likely make other aspects worse.
>

There is no trade-off. Either you can use this approach or you simply don't
and use the slightly longer form. This doesn't mean the current approach we
use can't continued to be used, just that the simple case can be made
really simple.

> I don't think there would be any problem at grouping the two
> import_fresh_module() in a single call that returns the two modules though.

And that can still be a useful thing for the class; for test modules whose
needs are simply too complicated then the instantiated instance can be
nothing more than a streamlined way of getting at both modules.

>  (I would also avoid the use of pep399 in the names -- it's not really
> readable unless you can map pep numbers with their titles.)

I came up with the name on the fly when I could think of anything better in
5 seconds. =) I assumed a different name would be used if this approached
was decided upon and went into test.support.