[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

Guido van Rossum guido at python.org
Wed Jul 16 21:57:47 CEST 2008


Having skimmed much material about proposed changes to the venerable
unitest module, I'd like to set some boundaries. PEPs that don't
follow the following rules are very unlikely to be accepted.

1. The API is not going to be renamed to PEP-8 conformance. This
notwithstanding the purported outcome of earlier discussions. The
renaming will cause too much grief for 3rd party developers; tracking
down why unittests fail is hard enough without also having to consider
changes to the unittest infrastructure itself. It's not the end of the
world if some standard API doesn't follow the style guide.

2. Radical changes to the API are off the table. If a radically
different API is to be accepted, the road to such acceptance is not a
design-by-committee PEP, but adoption of a 3rd party module with a
multi-year track record. If you have radically different ideas about
how to do unittesting, by all means implement them and try them out
and try to get a large audience to use them. When you are successful
in all that, *then* we'll talk about adoption into the standard
library.

3. I like assertEqual better than failUnlessEqual (and similar for all
assert* versions in favor of their fail* alias), and I don't like that
there is both assertEqual and assertEquals. But rule #1 means we have
to live with the aliases. At best we can discourage the undesirables
by documenting them out of existence.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list