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 at 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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4