Guido van Rossum <guido@python.org> writes:
The best thing to do would perhaps to make __mro__ assignable, but with a check that ensures the above constraint. I think I'd take a patch for that.
Shouldn't be too hard.
I'd also take a patch for assignable __bases__. Note that there are constraints between __bases__ and __base__.
Should assigning to __bases__ automatically tweak __mro__ and __base__? Guess so.
Yes. Note that changing __base__ should not be done lightly -- basically, the old and new base must be layout compatible, exactly like for assignment to __class__.
OK. I can crib code from type_set_class, I guess. Or one could just allow assignment to __bases__ when __base__ doesn't change? __base__ is object for the majority of new-style classes, isn't it? Brr. There's a lot I don't know about post 2.2 typeobject.c.
What would assigning to __base__ do in isolation? Perhaps that shouldn't be writeable.
Perhaps it could be writable when __bases__ is a 1-tuple.
Don't see the point of that.
But it's fine if it's not writable.
Easier :)
I'd also take a patch for assignable __name__.
This is practically a one-liner, isn't it? Not hard, anyway.
Probably. Can't remember why I didn't do it earlier.
It's a bit more complicated than that. What's the deal wrt. dots in tp_name? Is there any way for a user defined class to end up called "something.somthing_else"? Oh, and while we're at it, here's a bogosity:
class C(object): ... pass ... C.__module__ '__main__' C.__module__ = 1 C.__module__ Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: __module__
caused by lax testing in type_set_module.
And there was me wondering what I was going to do this evening.
I don't have that problem -- a Zope customer problem was waiting for me today. :-(
Well, I didn't get it finished either. Fiddly, this stuff. Maybe by tomorrow. Cheers, M. -- The Internet is full. Go away. -- http://www.disobey.com/devilshat/ds011101.htm