On Sun, Mar 29, 2009 at 9:42 AM, Antoine Pitrou solipsis@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.