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

Tim Peters tim.peters at gmail.com
Thu Aug 19 07:05:50 CEST 2004


[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?
> I'd rather be safe than sorry.

The "optimize unary minus" optimization Brett mentioned was the cause
of at least 3 distinct bugs, from gross (threw away entire parse
subtrees in some cases) to achingly subtle (excruciating consequences
from losing the distinction between plus and minus *floating* zeroes
after going thru marshal after the optimization), and which took more
than a year to discover from first to last.

Here's a bug opened this month against the peephole optimizer in 2.3
(and still in 2.4a2):

    http://www.python.org/sf/1004088

IME, optimizing has a much higher subtle-bug-per-line-of-code
ratio,than any other kind of programming work excepting cowboy
undisciplined approaches to threading.  But since I made my living
writing optimizing compilers (for threaded programs -- heh) at the
time we first corresponded about Python, I may have influenced you
toward being too jittery.  Kinda like I've scared everyone to death
about ZODB's BTrees in recent times, despite that they've been solid
as a rock for at least a year <0.5 wink>.

Python's optimizations are still so endearingly unambitious that I
don't think they're any more dangerous than the rest of Python.  For
example, I've spent far more of my recent life tracking down horrid
consequences of seemingly minor changes in asyncore.py.  So while
optimizations have been a source of bugs, they've been a very minor
source.  I also really appreciate that -O *doesn't* add "new bugs".  I
also really appreciate that bytecode optimizations are still so
unambitious that the relationship between btye code and source code
remains obvious.


More information about the Python-Dev mailing list