[Patches] [ python-Patches-736730 ] Trivial improvement to NameError message

SourceForge.net noreply@sourceforge.net
Fri, 27 Jun 2003 12:14:18 -0700


Patches item #736730, was opened at 2003-05-12 17:52
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736730&group_id=5470

Category: Core (C code)
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Trivial improvement to NameError message

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2003-06-27 14:14

Message:
Logged In: YES 
user_id=44345

Nobody seemed to like it, so I'm closing.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-05-12 20:37

Message:
Logged In: YES 
user_id=44345

That's also fine.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-05-12 20:27

Message:
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).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2003-05-12 19:57

Message:
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.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-05-12 18:16

Message:
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.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-12 18:05

Message:
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?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736730&group_id=5470