Bug in New Style Classes

[Michael Hudson]

michele.simionato at poste.it (Michele Simionato) writes:

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

You get an exception.  Obviously.  Did you actually read what I said?

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

Beats me too!  Maybe it's because you haven't written a patch yet :-)

Cheers,
mwh

-- 
  I think if we have the choice, I'd rather we didn't explicitly put
  flaws in the reST syntax for the sole purpose of not insulting the
  almighty.                                    -- /will on the doc-sig