[Python-Dev] pyc files, constant folding and borderline portability issues

Guido van Rossum guido at python.org
Mon Apr 6 23:28:41 CEST 2009

On Mon, Apr 6, 2009 at 1:22 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
> On Mon, Apr 6, 2009 at 9:05 PM, Raymond Hettinger <python at rcn.com> wrote:
>> The code for the lsum() recipe is more readable with a line like:
>>  exp = long(mant * 2.0 ** 53)
>> than with
>>  exp = long(mant * 9007199254740992.0)
>> It would be ashamed if code written like the former suddenly
>> started doing the exponentation in the inner-loop or if the code
>> got rewritten by hand as shown.

Do you have any evidence that people write lots of inner loops with
constant expressions? In real-world code these just don't exist that
much. The case of constant folding in Python is *much* weaker than in
C because Python doesn't have real compile-time constants, so named
"constants" are variables to the compiler.

> Well, I'd say that the obvious solution here is to compute
> the constant 2.0**53 just once, somewhere outside the
> inner loop.  In any case, that value would probably be better
> written as 2.0**DBL_MANT_DIG (or something similar).

So true.

> As Antoine reported, the constant-folding caused quite
> a confusing bug report (issue #5593):  the problem (when
> we eventually tracked it down) was that the folded
> constant was in a .pyc file, and so wasn't updated when
> the compiler flags changed.

Right. Over the years the peephole optimizer and constant folding have
been a constant (though small) source of bugs. I'm not sure that there
is much real-world value in it, and it is certainly not right to
choose speed over correctness.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list