[ python-Bugs-1014215 ] Unspecific errors with metaclass

[SourceForge.net]

Bugs item #1014215, was opened at 2004-08-23 10:33
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1014215&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Michael Hudson (mwh)
Summary: Unspecific errors with metaclass

Initial Comment:
Metaclass errors give only unspecific tracebacks.
The attached sample, with Python 2.3:

Traceback (most recent call last):
  File "mc.py", line 10, in ?
    class Z(X, Y):
TypeError: Cannot create a consistent method resolution
order (MRO) for bases X, Y

With Python 2.4, it prints:

Traceback (most recent call last):
  File "mc.py", line 10, in ?
    class Z(X, Y):
TypeError: Error when calling the metaclass.
Make sure the base arguments are valid.


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

>Comment By: Michael Hudson (mwh)
Date: 2004-09-10 14:55

Message:
Logged In: YES 
user_id=6656

> The core issue is that the lower level routines don't know
> enough to create an informative error message

That needs to be at least somewhat equivocal: sometimes they
do...

Isn't the attached sufficient?  It makes the word 'module'
appear in the error message you get when you try to subclass
a module, at least.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-08-23 17:07

Message:
Logged In: YES 
user_id=80475

Since 2.398 only replaces one type error with another, it's
really just about the contest of the error message.  Feel
free to remove or clarify the new message.

The core issue is that the lower level routines don't know
enough to create an informative error message and yet the
high level routines don't want to mask the information that
was available at the lower level.  Without considerable
effort, some of the error messages will be completely opaque
and uninformative, cryptic, or misleading (bug 963956 being
a prime example).

My preference is to opt for the higher level message, but
tastes vary.  

If you want to go for the gold, one possibility is to
capture the text of the lower level TypeError and append it
to the high level message.  The resulting messages may be
scary but at least they'll point a specific cause and be
suggestive of how to fix it.

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

Comment By: Michael Hudson (mwh)
Date: 2004-08-23 12:36

Message:
Logged In: YES 
user_id=6656

Argh argh argh.

This is a result of fixing bug #963956.  While the fix was well-
intentioned, I don't know if it's really the right thing... I suspect 
putting a more informative message in module_new might suffice.

Raymond's way of fixing the bug also neatly (and 
presumbably accidentally) sidestepped the tests that attempted to 
make sure you got a decent error message for this.

Raymond, what do you think?  I don't think the check in 
ceval.c:build_class can survive as is.

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

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