On Sun, Nov 17, 2013 at 1:05 PM, Maciej Fijalkowski <fijall@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)