Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Sun, Mar 30, 2008 at 5:01 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2506> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com