__setslot__(self, name, newvalue)
__getslot__(self, name)
__callmethod__(self, name, *args)
or something similar. If these methods are defined for an instance (in
its class, or one of its base classes), the interpreter would call these
to handle the access event.
Because these methods would get inherited by subclasses (just like special
methods such as __len__() do now), they'd be visible from instances-- a
normal class could be used like a 'metaclass' by defining these methods,
and letting other 'real' classes be derived from it. I.e., any class
could potentially be a 'metaclasses', by defining or over-riding these
special methods.
It seems that this would be alot simpler to implement, and might avoid
a major can-of-worms, design-wise. There's no new 'metaclass' feature
(only a set of new 'special' method names), and no syntax changes.
It also seems like this would be simpler to use, since there's no special
syntax or semantics for meta-classes. For example, it would use the usual
'class' resolution, for multiple inheritance ambiguity.
I concur that catching class item accesses could be a very useful
feature, in general. The only concerns I'd raise:
- Impact on class performance: in general, classes are already pretty
slow, and I'd rather see their perfomance optimized than worsened.
The extra overhead may be trivial here.
- Potential for misuse: I suspect it might get used in cases where
it would be simpler to define wrapper classes, use normal class
inheritance, etc. For example, data is usually wrapped in get/set
members in C++ coding, for better encapsulation; avoiding this
step alone doesn't justify the feature (I realize there's other
reasons).
- Potential for abuse: exposing the guts of class access like this
could lead to alot of hard-to-understand tricky code (but so can
anything else :-).
But I agree: the feature has clear utility, as already pointed out.
I'd just like to see it kept simple.
Mark Lutz