17.11.2013 23:05, Guido van Rossum wrote:
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.
My problem with -O (and -OO) is that even though my code is valid (in
terms of the rule 'use assert only for should-never-happen cases') I
have no control over 3rd party library code: I can never know whether
doesn't it break if I turn -O or -OO on (as long as I do not analyze
carefully the code of the libraries I use, including writing regression
tests [for 3rd party code]...).
Woudln't it to be useful to add possibility to place an "optimisation
cookie" (syntactically analogous to "encoding cookie") at the beginning
of each of my source files (when I know they are "-O"-safe), e.g.:
# -*- opt: asserts -*-
or even combined with an encoding cookie:
# -*- coding: utf-8; opt: asserts, docstrings -*-
Then:
* The -O flag would be effectively applied *only* to a file containing
such a cookie and *exactly* according to the cookie content (whether
asserts, whether docstrings...).
* Running without -O/-OO would mean ignoring optimisation cookies.
* The -OO flag would mean removing both asserts and docstrings (i.e.
the status quo of -OO).
* Fine-grained explicit command line flags such as --remove-asserts and
--remove-docstings could also be useful.
(Of course, the '-*-' fragments in the above examples are purely
conventional; the actual regex would not include them as it does not
include them now for encoding cookies.)
Cheers.
*j
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com