Guido van Rossum <gu...@python.org> writes: > The potential for abuse in and of itself should not be an argument > against a feature; it must always be weighed against the advantages.
It's both, surely? The potential for abuse of something is an argument against it; *and* that argument should be weighed against other arguments. Or, in other words: the potential for abuse of a feature is an argument that should not be discarded solely because there are advantages to that feature. > The argument that a unittest framework shouldn't be "abused" for > regression tests (or integration tests, or whatever) is also bizarre > to my mind. Surely if a testing framework applies to multiple kinds of > testing that's a good thing, not something to be frowned upon? To my mind, an API should take a stand on the “right” way to use it, rather than being a kitchen-sink of whatever ideas had any support. Doing something the right way should be easy, and doing something the wrong way should be awkward. This must be balanced, of course, with the principle that easy things should be easy and difficult things should be possible. But it doesn't necessarily conflict; we just need to take care that the easy and the right align well :-) > There are several alternative testing frameworks available outside the > standard library. The provide useful competition with the stlib's > unittest and doctest modules, and useful inspiration for potential new > features. They also, by and large, evolve much faster than a stdlib > module ever could, and including anyone of these in the stdlib might > well be the death of it (just as unittest has evolved much slower > since it was included). Right. This is an argument in favour of being assertive and parsimonious in the design of the standard-library ‘unittest’ API: this is the clear and obvious way to use this API, and if someone wants to do it a different way there are alternatives available. > But unittest *is* still evolving, and there is no reason not to keep > adding features along the lines of your module/class setUp/tearDown > proposal (or extra assertions like assertListEqual, which I am happy > to see has been added). That's a dismissal of the reasons that have been presented, without actually countering those reasons. > Anyway, Michael, thanks for getting this started -- I support your > attempts to improve the unittest package and am writing in the hope > that the discussion will soon converge and patches whipped up. Ditto. -- \ “I have had a perfectly wonderful evening, but this wasn't it.” | `\ —Groucho Marx | _o__) | Ben Finney _______________________________________________ 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
