On 28 April 2011 23:07, Guido van Rossum <gu...@python.org> wrote: > On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger > <raymond.hettin...@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 <gu...@python.org> wrote: >>>> On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé <ziade.ta...@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. :-)
Personaly I'd love to get rid of all of -O's meanings apart from setting __debug__ to False. Then you can write a strip tool which could strip all docstrings, just unused docstrings (an improvement over -O), and any "dead" code resulting from setting __debug__ to either True or False. The last thing to do is place assert statements inside a if __debug__ block. That way you could use the strip tool on the modules under test but not on the test modules. Regards Floris PS: I actually wrote some prototype code for such a strip tool last year but never finished it off, so I'm pretty sure most of this is possible. -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.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
