[Python-Dev] PEP: Consolidating names and classes in the `unittest`module (updated 2008-07-15)
fuzzyman at voidspace.org.uk
Tue Jul 15 04:14:47 CEST 2008
Raymond Hettinger wrote:
>> Replaces ``setUp(…)``
> . .
>> 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.
setUp and tearDown should become setup and teardown.
> 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
Well... "assert_not_equal" is slightly shorter, "assert_notequal"
slightly more so. Still one char longer than the original though.
> 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',
> arg2 +
> # 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 would allow you to use properties in testcases. Not sure if there is
a usecase for this though.
It looks like Benjamin Peterson is right, in Python 2.5 TestCase already
appears to be a new style class:
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import unittest
> It seems like a risky change for zero-benefit.
Looks like that part of the PEP is unnecessary.
> Python-Dev mailing list
> Python-Dev at python.org
More information about the Python-Dev