On Sun, Mar 30, 2008 at 5:01 PM, Raymond Hettinger
<report@bugs.python.org> wrote:
..
>  Weigh the cost/benefit carefully before pushing further.  I don't doubt
>  the legitimacy of the use case, but do think it affects far fewer than
>  one percent of Python programmers.

I agree with you, but only because fewer than 1% of Python programmers
have complete test coverage for their code. :-) On the other hand, I
wanted a no-optimize option regardless of the trace issue.  Once it is
there, I am sure everyone interested in how python compiler works will
use it.  (I am not sure what % of Python programmers would fall into
that category.)

I don't know how big of a deal an extra buildbot is, but I don't think
it will be necessary.  It is hard to imagine optimization that would
fix (mask) errors in non-optimized code.  Therefore, a non-optimized
buildbot is unlikely to flag errors that ar not present in optimized
runs.  On the other hand errors introduced by optimizer will be easier
to diagnose if they disappear when the code runs without optimization.

Mental overhead is important, but I think it will be easier to explain
the effect of no optimize option than to explain what -O does in the
current version.  As far as I can tell, -O has nothing to do with
peephole optimization and only removes assert statements and replaces
__debug__ with 0.  I am sure most python users are not aware of the
fact that peephole optimization is performed without -O option.

>  My feeling is that adding a new compiler option using a cannon to kill
>  a mosquito.  If you decide to press the case for this one, it should go
>  to python-dev since command line options affect everyone.
>

As an alternative to the command line option, what would you say to
making sys.flags.optimize writeable and disable peepholer if
Py_OprimizeFlag < 0?  This will allow python tracing tools to disable
optimization from within python code.  The fact that setting
sys.flags.optimize flag will not affect modules that are already
loaded  is probably a good thing because tracing code itself will run
optimized.   Such tracing tools may also need to use a custom importer
that would ignore precompiled code and effectively set
dont_write_bytecode flag.

>  This little buglet has been around since Py2.3.  That we're only
>  hearing about it now is a pretty good indicator that this is a very
>  minor in the Python world and doesn't warrant a heavy-weight solution.
>

I still maintain that this is not a bug.  Not hearing about it before
is probably an indication that users sophisticated enough to try to
achieve full test coverage for their code were able to recognize false
coverage gaps as such.