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

Michael Foord fuzzyman at voidspace.org.uk
Wed Jul 16 22:03:18 CEST 2008

Guido van Rossum wrote:

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.

I'm glad to see a pronouncement.

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.

I assume this doesn't rule out the addition of [some of..] the new convenience test methods?

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.

Presumably new methods should not follow PEP8 but be internally consistent with the existing API?

Does this mean that new methods should be added with both assert* and fail* names?

Michael

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