[Python-Dev] Accessing globals without dict lookup

Aahz Maruch aahz@rahul.net
Sun, 10 Feb 2002 16:41:34 -0800 (PST)


Guido van Rossum wrote:
> 
>> [Skip]
>>> In the face of exec statements or calls to execfile can't the
>>> compiler just generate the usual LOAD_NAME fallback instead of the new-
>>> fangled LOAD_GLOBAL opcode?
> 
> [Tim]
>> Note that exec doesn't have to be passed a string: you can pass it a
>> compiled code object just as well.  The compiler can't guess how a
>> code object will be used at the time it's compiled.  In theory there
>> would be nothing to stop exec from rewriting the bytecode in a
>> compiled code object passed to it, but I doubt we could get Guido to
>> buy that trick until he first buys rewriting bytecode to set
>> debugger breakpoints <wink>.
> 
> Arg.  So much for that idea.  (Although I think the mutable bytecode
> idea *is* the right idea for setting breakpoints after all.)

Let me play stupid for a sec: how does a compiled code object get
created?  Is Tim saying that one can pass foo.bar to exec, where bar()
is a function in module foo?  If not, why can't we force compile() to
generate the slower code?  Alternatively, can we change the semantics of
exec to require the use of compile() to generate code objects?
(compile() on an existing code object would do an explicit rewrite of
the bytecode.)
-- 
                      --- Aahz (@pobox.com)

Hugs and backrubs -- I break Rule 6       <*>       http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista

We must not let the evil of a few trample the freedoms of the many.