There are also peephole optimization. Removing it may prevent false positives for coverage tool http://bugs.python.org/issue2506
On Sat, Sep 10, 2016 at 4:01 AM Steven D'Aprano <st...@pearwood.info> wrote: > On Sat, Sep 10, 2016 at 10:04:46AM +1000, Damien George wrote: > > > I guess my main question to this list is: if CPython were to add a > > function to change the optimisation level at runtime, what would it > > look like? > > I don't think it would look like sys.optimize(flag). At the very least, > it would have to take *at least* three values: > > - no optimizations (the default) > - remove asserts (-O) > - remove asserts and docstrings (-OO) > > but even that is very limiting. Why can't I keep asserts, which may be > useful and important in running code, but remove docstrings, which > mostly are used interactively? I think the idea of "optimization levels" > has reached its use-by date and we should start considering separate > flags for each individual optimization. > > In particular, I expect that some time soon somebody will propose at > least one more optimization: > > - remove annotations > > and I seem to recall somebody requesting the ability to turn off > constant folding, although I don't remember why. I can easily imagine > Python implementations offering flags to control more complex/risky > optimizations: > > - resolve built-in names at compile-time[1] > - inline small functions > - unroll loops > > etc. Victor Stinner is (I think) working on bringing some of these to > CPython, and it seems to me that if they are to be under any > user-control at all, a simple optimization level counter is not going to > be sufficient. We're going to need a set of flags. > > But it seems to me that the ability to change optimizations at runtime > would be rather confusing. Shouldn't optimizations, or at least some of > them, apply on a per-module basis rather than globally? > > I don't even know how to reason about code optimizations if any function > I run might have changed the optimization level without my knowledge. So > I think this is a very dubious idea. > > > > > > > [1] Yes, I know that will change the semantics of Python code. > > > -- > Steve > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Thanks, Andrew Svetlov
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
