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/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
