[Python-ideas] [Python-Dev] the role of assert in the standard library ?
mal at egenix.com
Thu Apr 28 14:49:22 CEST 2011
Tarek Ziadé wrote:
> This is a thread from python-dev I am moving to python-ideas, because
> I want to debate the "assert" keyword :)
> On Thu, Apr 28, 2011 at 12:27 PM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>> On 28/04/2011 09:34, Terry Reedy wrote:
>>> On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
>>>> I removed some assert calls in distutils some time ago because the
>>>> package was not behaving correctly when people were using Python with
>>>> the --optimize flag. In other words, assert became a full part of the
>>>> code logic and removing them via -O was changing the behavior.
>>>> 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 :)
>>> My understanding is that assert can be used in production code but only to
>>> catch logic errors by testing supposed invariants or postconditions. It
>>> should not be used to test usage errors, including preconditions. In other
>>> words, assert presence or absence should not affect behavior unless the code
>>> has a bug.
> But it does affect the behaviour at the end: when the code has a bug,
> then the way the code works is affected and differs depending if -O is
"assert"s are meant to easily and transparently include testing
code in production code, without affecting the production
version's performance when run with the -O flag.
In your example, you can assume that your code does
indeed do what it's meant to do in production code, because
you will have tested the code in your test environment.
Assuming that you don't allow untested code to run on a production
system, you can then safely remove the assert bytecodes from
the program and avoid the added overhead using the -O flag.
For longer pieces of testing code, you can use:
This code will also get removed by the -O flag.
Both methods allow testing complex code without having to
duplicate much of the code in test cases, just to check
certain corner cases.
> Let me take an example:
> bucket = 
> def add(stuff):
> def purge_and_do_something():
> assert len(bucket) == 0
> ... do something by being sure the bucket is empty ...
> here, we could say assert is legitimate, as it just checks a
> post-condition. But this code is not thread-safe and if it's run via
> several threads, some code could add something in the bucket while
> purge() check for the assertion.
> So, if I run this code using -O it will not behave the same: it will
> seem to work. I am not arguing against the fact that this code should
> be changed and set up a lock.
> My point is that I do not understand why there are assert calls to
> check post-conditions. Those seem to be relics from the developer that
> marked something she needed to take care of in her code, but did not
> yet. e.g. like a TODO or a XXX or a NotImplementedError
> Moreover, why -O and -OO are removing assertions in that case ? even
> if the assert is "supposed not to happen" it's present in the code and
> can happen (or well, remove it). So "optimize" potentially changes the
> behaviour of the code.
>>From what I understood so far, a line with an assert should be
> considered as a dead code if we want the code to behave always the
> same way. I remove dead code in my code...
Professional Python Services directly from the Source (#1, Apr 28 2011)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2011-06-20: EuroPython 2011, Florence, Italy 53 days to go
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the Python-ideas