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

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