On Sep 12, 7:23 pm, [EMAIL PROTECTED] (Alex Martelli) wrote: > Carl Banks <[EMAIL PROTECTED]> wrote: > > ... > > > How about this? The decorator could generate a bytecode wrapper that > > would have the following behavior, where __setlocal__ and > > __execute_function__ are special forms that are not possible in > > Python. (The loops would necessarily be unwrapped in the actual > > bytecode.) > > I'm not entirely sure how you think those "special forms" would work. > > Right now, say, if the compiler sees somewhere in your function > z = 23 > print z > it thereby knows that z is a local name, so it adds a slot to the > function's locals-array, suppose it's the 11th slot, and generates > bytecode for "LOAD_FAST 11" and "STORE_FAST 11" to access and bind that > 'z'. (The string 'z' is stored in f.func_code.co_varnames but is not > used for the access or storing, just for debug/reporting purposes; the > access and storing are very fast because they need no lookup). > > If instead it sees a "print z" with no assignment to name z anywhere in > the function's body, it generates instead bytecode "LOAD_GLOBAL `z`" > (where the string `z` is actually stored in f.func_code.co_names). The > string (variable name) gets looked up in dict f.func_globals each and > every time that variable is accessed or bound/rebound.
Withdrawn. For some reason it was in my mind that variables not bound within in the function would be local. :| [snip] > > This wouldn't be that much slower than just assigning local variables > > to locals by hand, and it would allow assignments in the > > straightforward way as well. > > The big performance hit comes from the compiler having no clue about > what you're doing (exactly the crucial hint that "assigning local > variables by hand" DOES give the compiler;-) Right. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
