[Python-Dev] PEP: Consolidating names and classes in the unittestmodule (updated 2008-07-15) (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Tue Jul 15 04:14:47 CEST 2008

Raymond Hettinger wrote:

setup(…) Replaces setUp(…) . . teardown(…) 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 weirdmentalpause 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 isset). Go figure.

+1

setUp and tearDown should become setup and teardown.

failifalmostequal 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.testcase): def lostfourspacesherealready(self): self.failifalmostequal('were already on the 34th column before' 'writing anything substantive', self.testedobject.testedmethod(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.verylongmethodname 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/

More information about the Python-Dev mailing list