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

Guido van Rossum guido at python.org
Wed Jul 16 23:12:58 CEST 2008

On Wed, Jul 16, 2008 at 1:03 PM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:

Guido van Rossum wrote:

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?

Correct.

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?

Right again.

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

No, I don't see any reason to perpetuate that particular design snafu. I said "live with the aliases", not "add more of them".

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

More information about the Python-Dev mailing list