On Mon, 14 Jul 2008 04:27:40 pm Stephen J. Turnbull wrote:
> FWIW, I meant 10 != not not 10.
>>> 10 != not not 10
File "<stdin>", line 1
10 != not not 10
^
SyntaxError: invalid syntax
With respect, I think that the fact that you made an analogy with Python
code that you hadn't tested, got it wrong, then corrected it, and
*still* got it wrong, is telling. Its part of the pattern of this
thread. People have repeatedly and consistently asserted that their
particular favourite bike-shed colour is not just more attractive than
any other colour, but supposedly objectively and logically better than
any other colours. It's that second part that I object to.
When it comes to assert* versus fail* tests, this is one case where I
don't believe "one obvious way to do it" should apply. A similar, and I
hope uncontroversial, case is the greater-than and less-than operators.
It would be frankly silly to declare that Python code should always use
x < y and never y > x on the basis that there should be "one obvious
way". Sometimes a particular test is most naturally written as g-t, and
sometimes as l-t, and sometimes the choice between them is just
arbitrary.
I believe that assert* and fail* tests are the same: while the choice is
often arbitrary, sometimes a test is naturally written as an assert and
sometimes as a fail. My own tests often look like this:
fail_if_spam()
fail_unless_ham()
assert_parrot()
fail_if_spanish_inquisition()
because the specific parrot test is best written as an assertion rather
than a fail. And frankly, I simply don't believe that this imposes an
undue mental cost on people who might read my code.
It's certainly true that I could invert the nature of the tests:
assert_not_spam()
assert_ham()
assert_parrot()
assert_not_spanish_inquisition()
just for the sake of consistency (and that would be a good thing
*why*?), but only at the cost of inverting the code inside the test,
which may or may not be a simple thing to do.
--
Steven
_______________________________________________
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
