On Wed, Jul 16, 2008 at 1:03 PM, Michael Foord <[EMAIL PROTECTED]> 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/) _______________________________________________ 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
