On 11/02/2010 12:30, Nick Coghlan wrote:
Michael Foord wrote:
I'm not sure what response I expect from this email, and neither option
will be implemented without further discussion - possibly at the PyCon
sprints - but I thought I would make it clear what the possible
directions are.
I'll repeat what I said in the python-ideas thread [1]: with the advent
of PEP 343 and context managers, I see any further extension of the
JUnit inspired setUp/tearDown nomenclature as an undesirable direction
for Python to take.
Instead, I believe unittest should be adjusted to allow appropriate
definition of context managers that take effect at the level of the test
module, test class and each individual test.
For example, given the following method definitions in unittest.TestCase
for backwards compatibility:
def __enter__(self):
self.setUp()
def __exit__(self, *args):
self.tearDown()
The test framework might promise to do the following for each test:
with get_module_cm(test_instance): # However identified
with get_class_cm(test_instance): # However identified
with test_instance: # **
test_instance.test_method()
Well that is *effectively* how they would work (the semantics) but I
don't see how that would fit with the design of unittest to make them
work *specifically* like that - especially not if we are to remain
compatible with existing unittest extensions.
If you can come up with a concrete proposal of how to do this then I'm
happy to listen. I'm not saying it is impossible, but it isn't
immediately obvious. I don't see any advantage of just using context
managers for the sake of it and definitely not at the cost of backwards
incompatibility.
Michael
It would then be up to the design of the module and class context
manager instances to cache any desired common state. Further design work
would also be needed on the underlying API for identifying the module
and class context managers given only the test instance to work with.
The get_*_cm mechanisms would return a no-op CM if there was no specific
CM defined for the supplied TestCase.
Cheers,
Nick.
[1]
http://mail.python.org/pipermail/python-ideas/2010-January/006758.html
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
_______________________________________________
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
