This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients
Date 2005-03-04.02:55:03
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=593130

After more carefully reading the eval doc in Lib Ref 2.1, I agree 
that it needs improvement.  My suggestions (assuming that my 
experiment-based inferences are correct):

In 
"The expression argument is parsed and evaluated as a Python 
expression (technically speaking, a condition list) using the 
globals and locals dictionaries as global and local name space."
insert "in a new top-level environment" before 'using'. This says 
right-off, even if indirectly, that lexical scoping does not work 
across the eval call.

In
"If the locals dictionary is omitted it defaults to the globals 
dictionary."
insert "only" after "If'.  If both are omitted, it does not so default.  
Add a comma after 'omitted', as in the next sentence.

In
"If both dictionaries are omitted, the expression is executed in 
the environment where eval is called."
replace  "the expression ... is called", which I believe to be 
incorrect as well as misleading, with something like "they default 
to current globals() and locals()."  This parallels the previous 
sentence and is, I believe, more correct.  Within a function, 
locals() is not the current local namespace, and the following 
shows that the difference can make a visible difference:

>>> def g1(): return op.setitem(locals(), 'x', 1), x
...
>>> g1()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in g1
NameError: global name 'x' is not defined
>>> def h1(): return eval("op.setitem(locals(), 'x', 1), x")
...
>>> h1()
(None, 1)

After
"The return value is the result of the evaluated expression. "
add something like
It does not depend on the lexical position of the eval call and 
hence the expression should not contain names that require 
lexical scoping reaching outside the eval call to be valid."

Note that eval scope blocking, the OP's pseudobug, does not 
require a lambda within the eval-ed expression:
>>> def f(x): return lambda: x
...
>>> f(1)()
1
>>> def g(x): return lambda: eval('x')
...
>>> g(1)()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in <lambda>
  File "<string>", line 0, in ?
NameError: name 'x' is not defined

This might be another example for the PEP.
History
Date User Action Args
2007-08-23 14:29:50adminlinkissue1153622 messages
2007-08-23 14:29:50admincreate