[Types-sig] Re: Python Type System: An idea for unification
gmcm at hypernet.com
Sun Aug 29 16:33:08 CEST 1999
John (Max) Skaller wrote:
> At 10:05 28/08/99 -0500, Gordon McMillan wrote:
> >John (Max) Skaller wrote:
> > [Briefly, and subject to my misinterpretation, it appears that
> > Viper objects always have a type obj; said type obj may be
> > a class instance; said type obj is appended to the normal
> > attribute search path]
> "Usually" the type object will be a class, rather than
> an instance.
*That's* what I was missing.
So, to reiterate:
Given object x and type(x) == Y:
When type(Y) == ClassType & there exists Y.method:
x.method is resolved using the same plumbing as would occur in
stock Python if x were an instance of Y. That is, create a bound
method (x, Y.__dict__['method']). Thus the first arg to
'method', (normally called 'self') is the object x when invoked.
When type(Y) == InstanceType, Y.__class__ == Z, & there exsits
x.method is resolved as a bound method (x, Y.method), which is
really the doubly-bound method (x, (Y, Z.__dict__['method'])).
Thus the first arg to 'method' is the object Y, and the second
arg is the object x.
The changes from stock Python are:
1) Tweaking attribute lookup (appears to be a simplification!).
2) How objects are associated to types.
- builtins have a key that associates them to their type
objects thru a global dict
- users can create objects of arbitrary type thru a new
- extension writers have a bit more work to do, in that
something more sophisticated than a static C struct is
Is that a fair summary?
Do the type objects of modules, functions, tracebacks... (where the
new flexibility would not appear useful) follow these rules?
Have you thought at all about the current metaclass hook? That is,
a way of creating class instances where the type is something other
than the "stock" InstanceType? Or perhaps, the type of the
instance's class is something other than the "stock" ClassType?
More information about the Python-list