On Tue, 15 Jul 2008 06:32:53 pm Stephen J. Turnbull wrote:
Steven D'Aprano writes:
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.
It's telling only if you ignore the fact that it's the ad hominem fallacy.
The ad hominem fallacy does not mean "somebody pointed out I made a silly mistake". It is not a fallacy to reject a person's argument because it is hastily or carelessly made. However, fair is fair -- I too have to accept a slice of humble pie. In *my* haste to make my point, I neglected to actually make the point I intended to. I went on to write "It's part of the pattern of this thread" but didn't explain why. Namely that with so many people trying to push their personal preference, and signs of frustration on both sides, people are making unsupported statements of opinion as if they were facts, and generally getting sloppy. Ironic, yes? Having communicated poorly, and by doing so giving you offence, I will accept an appropriate fish-slapping.
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.
In the context you were talking about, where you don't need to show anybody your tests, I don't see any reason why TOOWTDI should apply. In a debugging context, I don't see any reason why it should, either.
But here we're talking about the standard unit-testing framework, which is used by Python itself.
But I'm using that same framework, so decisions made regarding that framework are going to impact me. Terry Reedy says that "stdlib modules are suggestions and examples, not commands", which is strictly true but I think he discounts just how strong the stdlib's influence is. Perhaps large projects, and tiny ones, are free to go their own way, but in my experience (such that it is), small projects tend to follow the stdlib.
So it *is* about communication with other developers, and it *does* make sense to avoid proliferation of redundant vocabulary.
Certainly redundant vocabulary has a cost, but it also has a benefit. At least for those people (including myself) who frequently think of a unit test as a sequence of potential failures rather than expected successes. Only if the code "fails to fail" does it pass the test, and so I often find fail* tests more suitable. YMMV. -- Steven