Python optimization (was Python's "only one way to do it" philosophy isn't good?)

[John Nagle]

Steve Howell wrote:
> --- John Nagle <nagle at animats.com> wrote:
> 
>>With this, the heavy optimizations are possible. 
>>Strength reduction.  Hoisting
>>common subexpressious out of loops.  Hoisting
>>reference count updates out of
>>loops.  Keeping frequently used variables in
>>registers.  And elimination of
>>many unnecessary dictionary lookups.
>>
> To the extent that some of these optimizations could
> be achieved by writing better Python code, it would
> nice for optimization tools to have a "suggest" mode. 
> For example, if I code a Fourier series and duplicate
> the subexpression n*f*t, it would be nice for a tool
> to tell me that I should refactor that expression. 
> Something like this:
> 
>    n*f*t should be refactored out of this expression,
> assuming muliplication has no desired side effects for
> n, f, and t.

      Too labor-intensive.  These are well understood optimizations
that can be done quite well automatically.  The problem is Python's
gratutious dynamism - it's hard to tell, when examining code, if
something can be patched by other code elsewhere.  Where "setattr"
is allowed, the compiler has to assume side effects almost everywhere.

				John Nagle