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

Guido van Rossum guido at python.org
Tue Apr 7 02:18:42 CEST 2009

On Mon, Apr 6, 2009 at 5:10 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Tue, 7 Apr 2009 07:27:29 am Guido van Rossum wrote:
>> Unfortunately the language reference is not the only thing we have to
>> worry about. Unlike languages like C++, where compiler writers have
>> the moral right to modify the compiler as long as they stay within
>> the weasel-words of the standard, in Python, users' expectations
>> carry value. Since the language is inherently not that fast, users
>> are not all that focused on performance (if they were, they wouldn't
>> be using Python). Unsurprising behavior OTOH is valued tremendously.
> Speaking as a user, Python's slowness is *not* a feature. Anything
> reasonable which can increase performance is a Good Thing.
> One of the better aspects of Python programming is that (in general) you
> can write code in the most natural way possible, with the least amount
> of scaffolding getting in the way. I'm with Raymond: I think it would
> be sad if "exp = long(mant * 2.0 ** 53)" did the exponentiation in the
> inner-loop. Pre-computing that value outside the loop counts as
> scaffolding, and gets in the way of readability and beauty.
> On the other hand, I'm with Guido when he wrote "it is certainly not
> right to choose speed over correctness". This is especially a problem
> for floating point optimizations, and I urge Cesare to be conservative
> in any f.p. optimizations he introduces, including constant folding.
> So... +1 on the general principle of constant folding, -0.5 on any such
> optimizations which change the semantics of a f.p. operation. The only
> reason it's -0.5 rather than -1 is that (presumably) anyone who cares
> about floating point correctness already knows to never trust the
> compiler.

Unfortunately, historically well-meaning attempts at adding
constant-folding have more than once introduced obscure bugs that were
hard to reproduce and only discovered one or two releases later. This
has little to do with caring about float correctness. It's more about
the difficulty of debugging Heisenbugs. For all these reasons should
be super risk averse in this area.

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

More information about the Python-Dev mailing list