Bug in New Style Classes

[Michele Simionato]

Michael Hudson <mwh at python.net> wrote in message news:<m3fz8uo356.fsf at pc150.maths.bris.ac.uk>...
> michele.simionato at poste.it (Michele Simionato) writes:
> > This is not a bug. The developers removed the possibility to change
> > the bases of a new-style class. 
> 
> Bad news for you: I put it back in for 2.3.

It is back!

> If you read the error message, you'll notice that it's phrased to
> suggest that assignment to __bases__ is *sometimes* possible :-)
> 
> David's assignment probably should work -- there's a bug on sf about
> this -- but there are definitely situations where assignment to bases
> *shouldn't* be allowed -- e.g. when the so-called 'solid base' changes
> -- but noone's put in the thinking time to make this precise in code.
> Being over-restrictive seems the better course.
> 

Uhm, I can see that in certain cases it may work, both what if a class 
has "object" as base and we change it to "type" ? What if we change 
the base class from new style to old style? What if we change one of 
the base classes with another one which is instance of a different 
metaclass? How do you solve the conflicts? What about ExtensionClasses and
replacing normal bases with C-coded ones? I see a recipe for disasters here, 
so that's why I thought the developer removed the option of changing the bases.
That would be understable. What I do not understand is why I cannot
change the __name__ of a function, what could possible go wrong with that??


                Michele