[Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320

[Tim Peters]

[Guido]
>> 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
>> time?
 
[David Abrahams]
> 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
> code.

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

    if __debug__:

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).