Issue528274
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.
Created on 2002-03-10 23:38 by alex_nanou, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
bug01.py | alex_nanou, 2002-03-10 23:38 | a script to demonstrate the bug (plese read the comments.) |
Messages (7) | |||
---|---|---|---|
msg9615 - (view) | Author: Alex A. Naanou (alex_nanou) | Date: 2002-03-10 23:38 | |
Bug confirmed. description: names that a in a scope just above the scome of the nested block (function) do not appear that functions globals thus bracking SOME (!) of the code that uses them. in particular the eval function, and all code that explicitly searces the name in the globals. code: //see the attached file. output: - a NameError raised in function nested_1: 'NameError: global name 'a' is not defined' - a NameError raised in function nested_2: 'NameError: name 'a' is not defined' workarround: explicitly pass the variable to the function as its default argument (as in nested_0). NOTE: declaring the name global does not work (as shown in function nested_1). //see the attached file for more details. test results: there appears to be a gap between the globals and the locals of a nested function. test systems: WIN2K v.5.00.2195 SP2 - ActivePython 2.2 Alpha 2 build 1 (ActiveState) Python 2.2a2+ (#22, Sep 5 2001, 14:10:41) [MSC 32 bit (Intel)] on win32 - Python 2.2 (#1, Dec 31 2001, 15:21:18) [GCC 2.95.3-5 (cygwin special)] on cygwin FreeBSD 4.5 (LocalBuild) Python2.2 //I do not remember the exact build. With Respect.. Alex. |
|||
msg9616 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-03-11 07:16 | |
Logged In: YES user_id=21627 It is not clear from your report what bug you are reporting. Please structure a bug report in the following way: - what did you do (you've explained this, providing a script) - what happened (you've also reported that) - what did you expect to happen instead (this is hard to find in your report) - why do you believe that the bug is in Python and not in your understanding of the language (optional) Analizing what you got as output: in your report: - NameError in nested_1: This is not a bug. You declare a as a global variable, yet there is no global variable with that name, hence the NameError. - NameError in nested_2: This appears to be a bug. See http://www.python.org/doc/current/ref/dynamic-features.html for a discussion of nested scopes and dynamic features. In your example, you reference the variable 'a' before using it in eval(), so it should be available to eval(). Notice, however, that removing the variable access from nested_2 also makes it unavailable to eval(). In the script, you argue that the variable should be either global or local. This is not true in Python 2.2, see http://www.python.org/doc/current/ref/nested-scopes.html |
|||
msg9617 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2002-03-12 22:31 | |
Logged In: YES user_id=31392 I think the bug report is trying to say that the error in the following code snippet is unexpected: def f(x): a = x def g(): return eval('a') return g f(3)() I'm not sure what the nested scopes appendix in the ref manual says, but I don't see that this is a bug I care to fix. (If it's a bug at all.) I don't believe the behavior of eval() is defined with respect to free variables bound in enclosing scopes. In practical terms, the compiler has no way to know that g() will try to access a in f(). |
|||
msg9618 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2002-03-12 22:34 | |
Logged In: YES user_id=31392 I just checked the language reference, Section A.3.2: > The builtin functions eval() and input() can not access free > variables unless the variables are also referenced by the > program text of he block that contains the call to eval() > or input(). |
|||
msg9619 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-03-13 09:38 | |
Logged In: YES user_id=21627 The attached script also has the example def f(x): a = x def g(): print a return eval('a') return g f(3)() which currently produces 3 Traceback (most recent call last): File "a.py", line 8, in ? f(3)() File "a.py", line 5, in g return eval('a') File "<string>", line 0, in ? NameError: name 'a' is not defined I believe this is a bug, since the variable a is referenced by the program text of the block that contains the call to eval(); thus, accessing a inside eval should work well; Reopening. |
|||
msg9620 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2002-03-13 21:39 | |
Logged In: YES user_id=31392 Yeah, I guess it would be nice if eval() behaved the way the refman suggests. It may be best to fix the refman and leave the code the way it is. eval() is a nuisance. |
|||
msg9621 - (view) | Author: Jeremy Hylton (jhylton) | Date: 2002-07-11 18:12 | |
Logged In: YES user_id=31392 This was actually fixed a while back. The checkin was even marked as a bug fix. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:05 | admin | set | github: 36237 |
2002-03-10 23:38:07 | alex_nanou | create |