[Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008年07月15日)

Tue Jul 15 04:06:49 CEST 2008

> ``set_up(…)``
> Replaces ``setUp(…)``
 . .
> ``tear_down(…)``
> Replaces ``tearDown(…)``

Am I the only one who finds this sort of excessive pep-8 underscoring to be horrorific?
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 weird_mental_pause 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 is_set). Go figure.
> fail_if_almost_equal

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.test_case):
 def lost_four_spaces_here_already(self):
 self.fail_if_almost_equal('were already on the 34th column before'
 'writing anything substantive',
 self.testedobject.tested_method(arg1, arg2 +
 arg3, arg4)
 # Imagine typing and line wrapping dozens more tests like this
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.very_long_method_name 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).
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.
Raymond 