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. -- --Guido van Rossum (home page: http://www.python.org/~guido/)