On 27/05/10 06:07, Colin H wrote:
In original Python, the snippet would have given an error whether you
thought of it as being in a class or function context, which is how
anyone who knew Python then would have expected. Consistency is not a bug.
When nested function namespaces were introduced, the behavior of exec
was left unchanged. Backward compatibility is not a bug.
Generally, most other behaviour did change - locals in enclosing
scopes *did* become available in the nested function namespace, which
was not backward compatible. Why is a special case made to retain
consistency and backward compatibility for code run using exec()? It's
all python code. Inconsistent backward compatibility might be
considered a bug.
Because strings are opaque to the compiler. The lexical scoping has *no
idea* what is inside the string, and the exec operation only has 3
things available to it:
- the code object compiled from the string
- the supplied globals namespace
- the supplied locals namespace
It isn't a special case, it's the only way it can possible work.
Consider a more complex example:
def get_exec_str():
y = 3
return "print(y)"
exec(get_exec_str())
Should that code work?
Or consider this one:
def get_exec_str():
y = 3
return "print y"
def run_exec_str(str_to_run):
y = 5
exec(str_to_run)
run_exec_str(get_exec_str())
Should that work? If yes, should it print 3 or 5?
Lexical scoping only works for code that is compiled as part of a single
operation - the separation between the compilation of the individual
string and the code defining that string means that the symbol table
analysis needed for lexical scoping can't cross the boundary.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
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
