[Python-Dev] Re: [Python-checkins] python/dist/src/Python
compile.c, 2.319, 2.320
tim.peters at gmail.com
Thu Aug 19 20:19:35 CEST 2004
>> Maybe I'm out of tune, but I thought that optimizations should be
>> turned off by default because most people don't need them and because
>> of the risk that the optimizer might break something. Haven't there
>> been situations in Python where one optimization or another was found
>> to be unsafe after having been in use (in a release!) for a long
> Isn't that a good argument for having them turned on all the time?
> The easiest way to ship code that suffers from an optimizer bug is to
> do all your development and most of your testing with unoptimized
That's my belief in this case (as I tried to say earlier, perhaps
unsuccessfully). The current peephole optimizer has been
overwhelmingly successful (the bug report I referenced was about
modules with more than 64KB of bytecode, and Python has always had
troubles of one kind or another with those -- so it grew another one
in that area, BFD), and I'm glad everyone runs it all the time.
> In C/C++, there's a good reason to develop code unoptimized: it's much
> easier to debug. I'm not sure that applies to Python.
It *used* to apply, and for a similar reason, when -O also controlled
whether SET_LINENO opcodes were generated, and the Python debugger was
blind without them. That's no longer the case. The only reason to
avoid -O now is to retain
blocks and (same thing) assert statements. That can make a big speed
difference in Zope and ZEO, for example. Life would definitely be
worse if -O could introduce new bugs (other than programmer errors of
putting essential code inside __debug__ blocks).
More information about the Python-Dev