greg at krypto
Jun 16, 2012, 5:04 PM
Post #10 of 10
On Thu, Jun 14, 2012 at 1:57 PM, "Martin v. L÷wis" <martin [at] v>wrote:
> > I don't really see the point. In my experience there is no benefit to
> > removing assert statements in production mode. This is a C-specific
> > notion that doesn't really map very well to Python code. Do other
> > high-level languages have similar functionality?
> It's not at all C specific. C# also has it:
> Java makes it a VM option (rather than a compiler option), but it's
> still a flag to the VM (-enableassertions):
> Delphi also has assertions that can be disabled at compile time.
It may be a commonly supported feature but that doesn't mean it is a good
It seems to me that assertion laden code where the assertions are removed
before shipping it or running it in production is largely a concept from
the pre-unittesting era. One big issue with them in Python is that
enabling or disabling them is VM global rather than controlled on a per
module/library basis. That isn't true in C/C++ where you can control it on
a per file basis at compile time (NDEBUG).
As a developer I agree that it is very convenient to toss asserts into code
while you are iterating on writing it. But I regularly have people remove
assert statements during code reviews at work and, if the condition is
important, replacing them with actual if condition checks that handle the
problem or raise an appropriate module specific exception and documenting
that as part of their API. At this point, I wish Python just didn't
support assert as part of the language because it causes less headaches in
the end of code is just written without them begin with. Too late now.
In agreement with others: docstring memory consumption is a big deal, some
large Python apps at work strip them or use -O (I don't remember which
technique they're using today) before deployment. It does seem like
something we should provide a standard way of doing. Docstring data is not
needed within non-interactive code.