RetroSearch Browse

Tue Jul 15 04:06:49 CEST 2008 · https://mail.python.org/pipermail/python-dev/2008-July/081107.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-July/081107.html below:

Consolidating names and classes in the `unittest`module (updated 2008-07-15)