Issue736730
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 2003-05-12 22:52 by skip.montanaro, last changed 2022-04-10 16:08 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
ceval.diff | skip.montanaro, 2003-05-12 22:52 |
Messages (7) | |||
---|---|---|---|
msg43698 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2003-05-12 22:52 | |
This is a trivial change, but since code may depend on the exact wording, I'm submitting a patch for review. The compiler knows when there's no locally bound name and generates LOAD_GLOBAL. If a NameError is raised during that instruction, it generates an error message like global name 'XYZ' is not defined This can be misleading to new users. The fact that the name is not found by LOAD_GLOBAL is strictly an optimization detail. I think something like the attached patch would be better. |
|||
msg43699 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2003-05-12 23:05 | |
Logged In: YES user_id=357491 +0 from me. Didn't we once agree that people depending on the exact text of an exception cause their own pain when the message gets changed? |
|||
msg43700 - (view) | Author: Tim Peters (tim.peters) * | Date: 2003-05-12 23:16 | |
Logged In: YES user_id=31435 For those who'd rather not read the patch first, the msg becomes name 'XYZ' not found in locals, globals or builtins I'm afraid I don't see in what sense that's an improvement! It gives less information, and glosses over the possibility of enclosing lexical scopes. When I see 'global' in the current msg, I know at once that the name isn't known in the local scope, or in any non-local but enclosing lexical scope. So unless I'm missing something, I'm -1 on this change. |
|||
msg43701 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2003-05-13 00:57 | |
Logged In: YES user_id=44345 The distinction between LOAD_NAME, LOAD_FAST and LOAD_GLOBAL is just an implementation detail. By saying name 'XYZ' not found in locals, globals or builtins you tell the user, "I looked in the locals, the globals and the builtins but didn't find XYZ." By saying global name 'XYZ' is not defined all you're telling the user is that you didn't find it in the globals. Look at it another way. The program would be correct if all the LOAD_FAST and LOAD_GLOBAL instructions were replaced by LOAD_NAME instructions (perhaps ignoring nested scopes). LOAD_NAME looks everywhere. The fact that the compiler can detect that XYZ isn't in the locals and can generate a LOAD_GLOBAL instruction instead doesn't mean all three scopes weren't searched. This arose by confusion from a user on c.l.py who had defined an object at class scope but then failed to reference it as "self.B". The NameError said the usual thing, which confused the user because he knew he hadn't defined the object at module scope. |
|||
msg43702 - (view) | Author: Tim Peters (tim.peters) * | Date: 2003-05-13 01:27 | |
Logged In: YES user_id=31435 Well, that same user also knew he hadn't defined the name in the locals or the builtins either, right? Telling him three confusing things isn't obviously better than telling him just one <wink>. If you think this is helpful, then I suggest name 'XYZ' is not defined would be more accurate (it doesn't omit the possibility of enclosing lexical scopes) and more pleasant (it's shorter). |
|||
msg43703 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2003-05-13 01:37 | |
Logged In: YES user_id=44345 That's also fine. |
|||
msg43704 - (view) | Author: Skip Montanaro (skip.montanaro) * | Date: 2003-06-27 19:14 | |
Logged In: YES user_id=44345 Nobody seemed to like it, so I'm closing. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:08:44 | admin | set | github: 38492 |
2003-05-12 22:52:44 | skip.montanaro | create |