On Thu, Feb 11, 2010 at 9:41 AM, Olemis Lang <ole...@gmail.com> wrote: > On Thu, Feb 11, 2010 at 7:41 AM, Michael Foord > <fuzzy...@voidspace.org.uk> wrote: >> 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() >>> >> > > What Nick pointed out is the right direction (IMHO), and the one I had > in mind since I realized that unittest extensibility is the key > feature that needs to be implemented . I even wanted to start a > project using this particular architecture to make PyUnit extensible. > It's too bad (for me) that I don't have time at all, to move forward > an just do it . > > :( > > I need days with 38 hrs !!! (at least) > > :$ > >> 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. >> > > AFAICS (so not sure especially since there's nothing done to criticize > ;o) is that backwards compatibility is not the main stopper ... > >> 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. >> > > ... but since I have nothing I can show you , everything is still in my mind > ... >
The idea (at least the one in my head ;o) is based on the features recently introduced in JUnit 4.7, especially the @Rule ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Free milestone ranch Download - mac software - http://feedproxy.google.com/~r/TracGViz-full/~3/rX6_RmRWThE/ _______________________________________________ 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
