[Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

[Guido van Rossum]

On Sun, Nov 17, 2013 at 1:05 PM, Maciej Fijalkowski <fijall at gmail.com>wrote:

> My problem with -O and -OO is that their arguments are very circular.
> Indeed, I understand the need why you would want in certain and
> limited cases to remove both docstrings and asserts. So some options
> for doing so are ok. But a lot of arguments I see are along the lines
> of "don't use asserts because -O removes them". If the option was
> named --remove-asserts, noone would care, but people care since -O is
> documented as "do optimizations" and people *assume* this is what it
> does (makes code faster) and as unintended consequence removes
> asserts.
>

It's circular indeed (and not just the shape of the letter :-).

I expect that if there was a separate --remove-asserts option, people would
write essential asserts and just claim "don't turn off asserts when using
this code". But that's just wrong because such an option (whether named -O
or --remove-asserts) is a global choice not under control of the author of
the program.

The correct rule should be "don't use assert (the statement) to check for
valid user input" and the stated reason should be that the assert statement
was *designed* to be disabled globally, not to be a shorthand for "if not
X: raise (mumble) Y". A corollary should also be that unittests should not
use the assert statement; some frameworks sadly encourage the anti-pattern
of using it in tests. (There are valid reasons to want to run unittests
with -O or -OO: for example, to validate that the code does not depend on
side effects of assert statements. If there was a --remove-asserts option,
running unittests with that option would be similarly useful.)

That said I think our man page and --help output could be more forthcoming
about this implication of "optimize". (The language reference is quite
clear about it.)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131117/8c2a2b94/attachment.html>