[ python-Bugs-1014215 ] Unspecific errors with metaclass

SourceForge.net noreply at sourceforge.net
Sun Sep 12 16:22:08 CEST 2004


Bugs item #1014215, was opened at 2004-08-23 10:33
Message generated for change (Settings changed) 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: 6
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 15:37

Message:
Logged In: YES 
user_id=6656

Unfortunately, I think

> Grab the text from the
> underlying TypeError and append it to the higher level
> message before re-raising TypeError.

might be a bit of a bear to implement.  If I'm being dumb
about this, feel free to apply the cluestick (bearing in
mind that in general stringifying the TypeError may execute
Python code).

There probably is no ideal solution to this -- it's a knotty
problem.  The problem with current CVS is that it can lose
information, whereas before it failed to add it...


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-09-10 15:22

Message:
Logged In: YES 
user_id=80475

If you want the best of all worlds.  Grab the text from the
underlying TypeError and append it to the higher level
message before re-raising TypeError.

I'm happy with whatever you decide to do.  When deciding, be
sure to consider bug #963956 -- it is a small disaster with
the msg appearing totally unrelated to what caused it.

And, no, the statement wasn't equivocal.  Low level routines
cannot know for all time and all situtations the context in
which they were called.  Sometimes they are fortunate and
tend to be called by only one thing or in just one context;
however, that is subject to change as soon as new high level
routine decides to use that building block.

In this particular case, the metaclass function call can
launch just about anything.  The callee really has no way of
knowing the circumstances of how it was called -- in this
case, one of the implicit actions of metaclasses.

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

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


More information about the Python-bugs-list mailing list