
On 5/21/14 7:41 AM, Nick Coghlan wrote:
On 21 May 2014 21:06, "Ned Batchelder" <ned@nedbatchelder.com <mailto:ned@nedbatchelder.com>> wrote:
** Implementation
Although it may seem like a big change to be able to disable the optimizer, the heart of it is quite simple. In compile.c is the only call to PyCode_Optimize. That function takes a string of bytecode and returns another. If we skip that call, the peephole optimizer is disabled.
** User Interface
Unfortunately, the -O command-line switch does not lend itself to a new value that means, "less optimization than the default." I propose a new switch -P, to control the peephole optimizer, with a value of -P0 meaning no optimization at all. The PYTHONPEEPHOLE environment variable would also control the option.
Since this is a CPython specific thing, a -X named command line option would be more appropriate.
I had overlooked the introduction of -X. Yes, that seems like the right way: -Xpeephole=0
There are about a dozen places internal to CPython where
optimization level is indicated with an integer, for example, in Py_CompileStringObject. Those uses also don't allow for new values indicating less optimization than the default: 0 and -1 already have meanings. Unless we want to start using -2 for less that the default. I'm not sure we need to provide for those values, or if the PYTHONPEEPHOLE environment variable provides enough control.
I assume you want the environment variable so the setting can be inherited by subprocesses?
It allows it to be inherited by subprocesses, yes. I was hoping it would mean the setting would be available deeper in the interpreter, but now that I think about it, environment variables are interpreted at the top of the interpreter, and then the settings passed along internally. I'll do a survey to figure out where the setting has to be plumbed through the layers to get to compile.c properly. --Ned.
Cheers, Nick.