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

[Guido van Rossum]

On Sun, Mar 29, 2009 at 9:42 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> There are a couple of ancillary portability concerns due to optimizations which
> store system-dependent results of operations between constants in pyc files:
>
> - Issue #5057: code like '\U00012345'[0] is optimized away and its result stored
> as a constant in the pyc file, but the result should be different in UCS-2 and
> UCS-4 builds.

Why would anyone write such code (disregarding the \U escape problem)?
So why do we bother optimizing this?

> - Issue #5593: code like 1e16+2.9999 is optimized away and its result stored as
> a constant (again), but the result can vary slightly depending on the internal
> FPU precision.

I would just not bother constant folding involving FP, or only if the
values involved have an exact representation in IEEE binary FP format.

> These problems have probably been there for a long time and almost no one seems
> to complain, but I thought I'd report them here just in case.

I would expect that constant folding isn't nearly effective in Python
as in other (less dynamic) languages because it doesn't do anything
for NAMED constants. E.g.

MINUTE = 60

def half_hour():
    return MINUTE*30

This should be folded to "return 1800" but doesn't because the
compiler doesn't know that MINUTE is a constant.

Has anyone ever profiled the effectiveness of constant folding on
real-world code? The only kind of constant folding that I expect to be
making a diference is things like unary operators, since e.g. "x = -2"
is technically an expression involving a unary minus.

ISTM that historically, almost every time we attempted some new form
of constant folding, we introduced a bug.

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