On Tue, Jul 15, 2008 at 12:06 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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.
>
Hi,
My name's Jonathan, and I spell "set up" as "set up" and "tear down"
as "tear down".
> 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.
>
Yes, guessability via consistency is the important thing here.
>
>> 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.
>
Well, "assert_" is strictly shorter than "fail_unless_".
>
>> * 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).
>
I find underscores easier to read—I suspect this will vary from person
to person. Typing isn't an issue since I use an auto-complete function
in my editor.
jml
_______________________________________________
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
