Which happens first?

[Tim Peters]

[Carlos Alberto Reis]
> ...
> My intention was to point out that some constructs are unexpectedly
> slow.

But they're also "unexpectedly dynamic", and the two are hard to separate.
Let's zoom ahead to the example:

> ...
> HEIGHT = 10
> WIDTH  = 10
> DEPTH  = 10
> z = map (lambda x: x * (HEIGHT * WIDTH * DEPTH), a)
>
> At first, you could think that there is nothing in this expression to
> optimize it.  However, the expression above is about 68% slower than
> the direct calculation:
>
> z = map (lambda x: x * 1000, a)

Note that the latter *may* compute something entirely different than the
original, so it's not a safe optimization.  The problem is that we don't know
what's in a, so we don't know what the "*" in "x *" means either:  it could
invoke any code whatsoever (via coercion and/or operator overloading
gimmicks) at runtime, including code that reaches into the module and changes
the bindings for any or all of HEIGHT etc.  The language is defined in such a
way that HEIGHT etc are looked up fresh on each iteration.

Of course it's rarely good practice to exploit that, but Python doesn't
forbid it.  Heck, we generally can't even know what "map" means at
compile-time (the names of builtins are not reserved, and sometimes people
even change their bindings in the __builtin__ module!).

the-point-to-wysiwyg-isn't-machine-efficiency-ly y'rs  - tim