My idea was to make the compiler smarter so that it would recognize
exec() even if it was just a function.
Another idea might be to change the exec() spec so that you are
required to pass in a namespace (and you can't use locals() either!).
Then the whole point becomes moot.
On 10/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> This might be minor-- but I didn't see anyone mentioning it so far.
> >> If `exec` functionality is to be provided, then I think it still
> >> should be a keyword for the parser to know; currently bytecode
> >> generation is affected if `exec` is present. Even if that changes
> >> for Python 3k (we don't know yet), the paragraph for exec should be
> >> annotated with a note about this issue.
>
> Brett> But the PEP says that 'exec' will become a function and thus no
> Brett> longer become a built-in, so changing the grammar is not needed.
>
> I don't think that was the OP's point though it might not have been terribly
> clear. Today, the presence of the exec statement in a function changes how
> non-local load instructions are generated. Consider f and g with their
> dis.dis output:
>
> >>> def f(a):
> ... exec "import %s" % a
> ... print q
> ...
> >>> def g(a):
> ... __import__(a)
> ... print q
> ...
> >>> dis.dis(f)
> 2 0 LOAD_CONST 1 ('import %s')
> 3 LOAD_FAST 0 (a)
> 6 BINARY_MODULO
> 7 LOAD_CONST 0 (None)
> 10 DUP_TOP
> 11 EXEC_STMT
>
> 3 12 LOAD_NAME 1 (q)
> 15 PRINT_ITEM
> 16 PRINT_NEWLINE
> 17 LOAD_CONST 0 (None)
> 20 RETURN_VALUE
> >>> dis.dis(g)
> 2 0 LOAD_GLOBAL 0 (__import__)
> 3 LOAD_FAST 0 (a)
> 6 CALL_FUNCTION 1
> 9 POP_TOP
>
> 3 10 LOAD_GLOBAL 2 (q)
> 13 PRINT_ITEM
> 14 PRINT_NEWLINE
> 15 LOAD_CONST 0 (None)
> 18 RETURN_VALUE
>
> If the exec statement is replaced by a function, how will the bytecode
> generator know that q should be looked up using LOAD_NAME instead of
> LOAD_GLOBAL? Maybe it's a non-issue, but even if so, a note to that affect
> on the wiki page might be worthwhile.
>
> Skip
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
