``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
_______________________________________________
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
