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?
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.
+1
setUp and tearDown should become setup and teardown.
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.
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',
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 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
>>> type(unittest.TestCase)
<type 'type'>
>>>
It seems like a risky change for zero-benefit.
Looks like that part of the PEP is unnecessary.
Michael
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/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/
_______________________________________________
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
