On Monday, December 23, 2013 12:05:22 PM UTC-5, Steven D'Aprano wrote:
> Roy Smith wrote:
> > And, yes, I know that assertions get turned off with -O (frankly, I
> > think that's a design flaw). We don't run with -O.
>
>
> Until such time as somebody decides they can speed up your code by 5% by
> running with optimizations turned on.
Well, there's lots of changes people could make that would break things. Many
of them are in the name of efficiency. [1] But, let's say they did that. We
would fall off the end of the function, return None, and the caller would end
up doing:
with None:
whatever
leaving somebody to puzzle over why the logs contained a stack dump ending in:
AttributeError: __exit__
So, here's the deeper question. Is your issue strictly that -O elides assert
statements? [2] That's a purely mechanical issue that could be solved by using
the rather more verbose:
if not condition:
raise AssertionError("....")
Would you feel differently then?
> So there's always tension between "why am I testing something that can't
> fail?" and "but what if it does?"
Trust, but verify. Especially when the thing you're verifying is your
understanding of how your own code works :-)
[1] and most of those are premature optimizations. To a first order
approximation, for us, application speed is all about database performance, and
not at all about Python code execution speed. That's a pretty good second
order approximation as well.
[2] In which case, we would just add some middleware which did:
assert "-O" not in sys.argv
--
https://mail.python.org/mailman/listinfo/python-list
