Raymond Hettinger wrote:
``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?
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 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
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.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).
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/
_______________________________________________
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
