[Python-Dev] the role of assert in the standard library ?
Holger Krekel
holger.krekel at gmail.com
Fri Apr 29 09:55:57 CEST 2011
On Fri, Apr 29, 2011 at 12:31 AM, Raymond Hettinger
<raymond.hettinger at 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 at 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 at python.org> wrote:
>>>>> On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé <ziade.tarek at 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
More information about the Python-Dev
mailing list