On Fri, Apr 29, 2011 at 12:31 AM, Raymond Hettinger raymond.hettinger@gmail.com wrote:
On Apr 28, 2011, at 3:07 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger raymond.hettinger@gmail.com wrote:
On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum guido@python.org wrote:
On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé ziade.tarek@gmail.com wrote:
In my opinion assert should be avoided completely anywhere else than in the tests. If this is a wrong statement, please let me know why :)
I would turn that around. The assert statement should not be used in unit tests; unit tests should use self.assertXyzzy() always.
FWIW this is only true for the unittest module/pkg policy for writing and organising tests. There are other popular test frameworks like nose and pytest which promote using plain asserts within writing unit tests and also allow to write tests in functions. And judging from my tutorials and others places many people appreciate the ease of using asserts as compared to learning tons of new methods. YMMV.
I've also observed that people appreciate using asserts with nose.py and py.test.
They must not appreciate -O. :-)
It might be nice if there were a pragma or module variable to selectively enable asserts for a given test module so that -O would turn-off asserts in the production code but leave them on in a test_suite.
A way to tell Python "if you are going to compile this module/path, don't turn off asserts, no matter what" would be great. Then nose/py.test and whichever tools/apps could fine-tune the handling of asserts. (This would probably be better than marking things inline for those use cases). Then testing with "-O" would work nicely as well which would be appreciated :)
best, holger
Raymond