Stephen J. Turnbull wrote:
Ben Finney writes:
> Removal of ``assert*`` names
> ----------------------------
> Arguments in favour of retaining only the ``assert*`` names:
>
> * BDFL preference: The BDFL has stated [#vanrossum-1]_ a preference
> for the ``assert*`` names.
>
> * Precedent: The Python standard library currently uses the
> ``assert*`` names by a roughly 8:1 majority over the ``fail*``
> names. (Counting unit tests in the py3k tree at 2008-07-15
> [#pitrou-1]_.)
>
> An ad-hoc sampling of other projects that use `unittest` also
> demonstrates strong preference for use of the ``assert*`` names
> [#bennetts-1]_.
>
> * Positive admonition: The ``assert*`` names state the intent of how
> the code under test *should* behave, while the ``fail*`` names are
> phrased in terms of how the code *should not* behave.
FWIW, I think these are fairly stated. So fairly that I'm surprised
you haven't been persuaded!<wink> Nitpick: the second point is not
just "precedent", there's an economic reason there too. Tests in the
standard distribution which use the deprecated style will need to be
converted. Steven d'Aprano claims this is nontrivial (and thus error-
prone) in some cases. I haven't seen that claim denied, and it seems
plausible to me.
I disagree with SdA's statement there: failUnless* maps directly to
assert* and failIf* maps directly to assertNot*. There are no semantic
changes whatsoever involved in that remapping, just a change in the
method names.
Note that if the API is to be rationalised at all, my personal
preference is to keep assert* and failIf* and get rid of their longer
counterparts (failUnless* and assertNot*). Alternatively, ditch the
binary assertion methods entirely, and use a check object to state those
assertions:
check(x).almost_equal(y) instead assertAlmostEqual(x, y)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
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
