Re: [Python-Dev] metaclass insanity
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
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?
But if you derive from a builtin type (e.g. list or dict), __base__ will be that.
Brr. There's a lot I don't know about post 2.2 typeobject.c.
Me too. :-)
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 :)
Agreed.
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"?
I hope not. The dots are for extensions living inside a package; everything before the last dot ends up as __module__.
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.
Oops. Can you fix it? Or are there complications? Seems to be broken in 2.2 too.
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.
Great! I'll be offline Friday through Monday -- going to a weekend conference. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum -
Michael Hudson