[Types-sig] Re: Python Type System: An idea for unification

[Gordon McMillan]

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
   Z.method:

     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
        builtin "new_object(type_object)"
      - extension writers have a bit more work to do, in that 
        something more sophisticated than a static C struct is
        required.

Is that a fair summary?

Questions:

 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?

listening-for-the-sound-of-a-down-under-brain-exploding-ly y'rs

- Gordon