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

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