[Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)
apieum at gmail.com
Sun Nov 17 14:08:57 CET 2013
I believe the point of removing assertions is also to avoid throwing
unhandled developper errors to end-user and not only "performance".
It's like "raise" without "try" block.
It's certainly because I consider "assert" as a developper util, providing
a concrete documentation about methods signatures.
In this idea I've made a small bench to determine if it is interesting for
an assertion lib to have null functions as default.
I don't make critical performance applications but still doubt of the real
interest of having dead code to better document.
2013/11/17 Steven D'Aprano <steve at pearwood.info>
> On Sun, Nov 17, 2013 at 11:35:21AM +0100, Antoine Pitrou wrote:
> > You didn't answer my question: did you actually use -OO in production,
> > or not? Saying that -OO could have helped you optimize something you
> > didn't care about isn't a very strong argument for -OO :)
> Ah, sorry, I misunderstood your question.
> I didn't use -OO, since I had no reason to remove docstrings. But I did
> use -O to remove asserts. I was talking about assertions, not
> docstrings. Since I haven't had to write code for embedded devices with
> severely constrained memory, I've never cared about using -OO in
> > What I would like to know is if people *knowingly* add costly asserts
> > to performance-critical code, with the intent of disabling them at
> > runtime using -OO.
> Yes, I have knowingly added costly asserts to code with the intend of
> disabling them at runtime. Was it *performance-critical* code? I don't
> know, that was the point of my earlier rambling -- I could demonstrate a
> speedup of the individual functions in benchmarks, but nobody spent the
> effort to determine which functions were performance critical.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev