R. David Murray wrote: > would be easier to write, be more maintainable, and be easier to > understand when reading the code than the equivalent setUp and tearDown > methods would be. > > I'm not saying it would be easy to implement, and as you say backward > compatibility is a key concern.
That's the gist of my thinking, yeah. However, a couple of problems of note that occurred to me after an extra day or so of musing on the topic: - the semantics I listed in my original post are broken, since a naive context manager couldn't be used (it would setup and tear down the resources for each test instance, which is what we're trying to avoid). Supporting naive context managers would require iterating over the test classes within the module CM and iterating over the instances within the class CM. - context managers fit best in more procedural code. They're tricky to invoke correctly from code that is split across several methods in different classes (as I believe unittest is), since you can't use a with statement directly to do the invocation for you So I think new setup*/teardown* methods and functions are likely to be a better fit for the unittest architecture. At a later date, it may be worth adding some mixins or other mechanisms that adapt from the unittest setup/teardown model to a CM based model, but to be honest, if I want to use a CM when testing, I'll generally create a more complex test method that iterates through a bunch of test inputs itself. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
