[Python-Dev] PEP: Consolidating names and classes in the unittestmodule (updated 2008-07-15) (original) (raw)

Steve Holden steve at holdenweb.com
Tue Jul 15 08:40:22 CEST 2008

Raymond Hettinger wrote:

setup(…) Replaces setUp(…) . . teardown(…) Replaces tearDown(…) Am I the only one who finds this sort of excessive pep-8 underscoring to be horrorific? Definitely not. I thin we are in danger of insisting on a foolish consistency. I'd far prefer readability (hence my preference for is_not over not_is). There's also the (possibly marginal) point that people used to Junit can actually understand Python unit tests right now. Surely there's something to be said for consistency across languages, especially when the idea was lifted from Java in the first place.

Nobody I know spells setup and teardown as two words. I dread using the module with these new names. Underscores are not fun to type. They create a weirdmentalpause when reading them.

It's not going to be easy to remember where they are used (ie. isinstance is still isinstance but isset is now isset). Go figure.

failifalmostequal Another thought is that test suite code is going to get seriously crunched when the new, longer method names meet the 78/80 column pep 8 restrictions. class TestMisc(unittest.testcase): def lostfourspacesherealready(self): self.failifalmostequal('were already on the 34th column before' 'writing anything substantive', self.testedobject.testedmethod(arg1, arg2 + arg3, arg4) # Imagine typing and line wrapping dozens more tests like this And the way Thunderbird has wrapped your example makes it obvious that 72 is a more satisfactory limit, though I agree transmissibility via email shouldn't necessarily be a factor.

Are there any ideas for some short, pithy, mnemonic names that are self-explantory and not full of underscores; something that wouldn't suck to type hundreds of times in a good test module? IMO, the current names are already too long.

* Explicit is better than implicit: Don't forgot the opposing forces: Beautiful is better than ugly. Readability counts. These are especially important for the unittest module. When I'm making tests, I have to type self.verylongmethodname so many times it isn't funny. It's easy to just stop writing tests when you get tired of it. Long api names with underscores are a disincentive (IMO). Use new-style classes throughout This makes sense for 3.1 but of course we already get that automatically for 3.0 ;-) For 2.7, it doesn't make as much sense. Since 2.2 came out, there have been many discussions on changing standard library code to use new-style classes. There was always some concern about subtle changes in semantics and for the most part these requests were denied. I think this reason applies with even more force to the unittest module. Any risk that we subtlely break someone's test-suite is a small disaster. The 2.6 and 2.7 unittests need to be absolutely stable if they are to serve as a transition tool (providing a baseline the 3.0/3.1 is expected to match). I'm not quite sure how often it has to be pointed out that since 2.5 all unittest classes are new-style classes. Benjamin has, I believe, already mentioned twice that unittest.py contains

metaclass = type

before any class declarations. While this has no effect on pre-2.2 implementations, surely it means that we've been using new-style classes for some time now. Or am I missing some subtlety? 2.5.1 says:

isinstance(unittest.TestCase, type) True

Also, are there any expected benefits from making this change in 2.7? What will the module do differently?

It seems like a risky change for zero-benefit. Better revert it, then :-)

But easier to just drop that sentence from the PEP.

regards Steve

Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

More information about the Python-Dev mailing list