newbie: self.member syntax seems /really/ annoying

[Carl Banks]

On Sep 12, 7:23 pm, al... at mac.com (Alex Martelli) wrote:
> Carl Banks <pavlovevide... at gmail.com> 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