[Python-Dev] assigning to new-style-class.__name__

Michael Hudson mwh@python.net
Wed, 27 Nov 2002 10:51:44 +0000 (GMT)

I'm sending this to python-dev as well.

On Tue, 26 Nov 2002, Guido van Rossum wrote:

["> >" and "> > >" are both me]

> > > Thinking about it, I'm expecting an exception that gets set to stay set 
> > > for quite a long time, and that may not be justified.  Can see a way past 
> > > that.
> > 
> > This is still a valid point; I need to test a class with a metaclass with 
> > a raising .mro()...
> Yes, I don't understand why you don't simply drop out when you set
> r = -1.

Well, currently I'm striving for leaving the system in a state of minimal 
inconsistency.  There are problems with what I have now, though.

Possibly the best solution is if any .mro() fails to abandon the whole 
procedure and leave things exactly as they are.  The difficulty with this 
is that I'd have to keep a list of which subclasses have had their mro's 
frobbed so I can unfrob them if a later subclasses .mro() fails.  This is 
just a matter of programming though.

How much I care about this would be influenced by an answer to the 
following problem:

In the following inheritance diagram:

...  ...   ...
 \   /     /
  \ /     /
   C     D
    \   /
     \ /

is it possible to rearrange the __bases__ of C in a way that doesn't 
create a conflict for C but does for E?  I haven't thought about MRO 
calculations at all, I'm afraid.