TBH you're completely right. Every time I see someone using unittest andItsHorriblyUnpythonicNames, I want to kill a camel. Sometimes, though, I feel like part of the struggle is the alternative. If you dislike unittest, but pytest is too "magical" for you, what do you use? Many Python testing tools like nose are just test *runners*, so you still need something else. In the end, many just end up back at unittest, maybe with nose on top. As much as I hate JavaScript, their testing libraries are leagues above what Python has. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone elsehttp://refi64.com On Aug 22, 2017 at 5:09 PM, > wrote: ** Caution: cranky curmudgeonly opinionated comment ahead: ** unitest is such an ugly Java-esque static mess of an API that there's really no point in trying to clean it up and make it more pythonic -- go off and use pytest and be happier. -CHB On Tue, Aug 22, 2017 at 5:42 AM, Nick Coghlan wrote:

On 22 August 2017 at 15:34, Nick Coghlan wrote:

...

On 21 August 2017 at 11:32, Neil Girdhar wrote:

...

This question describes an example of the problem: https://stackoverflow.com/questions/8416208/in-python- is-there-a-good-idiom-for-using-context-managers-in-setup-teardown. You want to invoke a context manager in your setup/tearing-down, but the easiest way to do that is to override run, which seems ugly.

Using context managers when you can't use a with statement is one of the main use cases for contextlib.ExitStack():

def setUp(self): self._resource_stack = stack = contextlib.ExitStack() self._resource = stack.enter_context(MyResource())

def tearDown(self): self._resource_stack.close()

I posted that as an additional answer to the question: https://stackoverflow.com/questions/8416208/in-python- is-there-a-good-idiom-for-using-context-managers-in- setup-teardown/45809502#45809502

Sjoerd pointed out off-list that this doesn't cover the case where you're acquiring multiple resources and one of the later acquisitions fails, so I added the ExitStack idiom that covers that case (using stack.pop_all() as the last operation in a with statement):

def setUp(self): with contextlib.ExitStack() as stack: self._resource1 = stack.enter_context(GetResource()) self._resource2 = stack.enter_context(GetOtherResource()) # Failures before here -> immediate cleanup self.addCleanup(stack.pop_all().close) # Now cleanup won't happen until the cleanup functions run

I also remember that using addCleanup lets you avoid defining tearDown entirely.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/