[Python-Dev] Class Methods

Donald Beaudry donb at abinitio.com
Fri Apr 20 17:19:56 EDT 2001


"Thomas Heller" <thomas.heller at ion-tof.com> wrote,
> > >>>>> "GvR" == Guido van Rossum <guido at digicool.com> writes:
> > 
> >     GvR> Let x be an object, C its class, and M C's class.  So,
> > 
> >     |   x.__class__ is C
> >     |   C.__class__ is M
> > 
> >     GvR> Then x's methods are described in C.__dict__, and C's methods
> >     GvR> are described in M.__dict__.
> > 
> >     GvR> The problem is that if you write C.spam, there could be two
> >     GvR> spams: one in C.__dict__, one in M.__dict__.  Which one to
> >     GvR> use?

In my 'objectmodule' I adopted a concept which I refer to as the
"unbound instance".  That is, I invented an object which is used as a
proxy for accessing instance attributes.  It looks like an instance
but only for the purposes of attribute access.  Now, since this object
will only return "unbound method objects" when accessing a method (as
opposed to the "bound method object" you would get when accessing a
method from a real instance) I thought the name was at least slightly
appropriate.  In short, each class defined by the objectmodule has a
special attribute '_' which is the "unbound instance" for that class.
This unbound instance is used to resolve the name ambiguity.  Now,
consider this:

    import object

    class foo(object.base):
        def frob(self):
            print "I've been frobbed", self

        class __class__:
            def frob(cl):
                print "No, I've been frobbed", cl


    >>> f = foo()
    >>> x = f.frob
    >>> # x is the instance frob method bound to f
    >>> y = foo.frob
    >>> # y is the class frob method bound to foo
    >>> z = foo._.frob
    >>> # z is the instance frob method but is not bound to any instance
    >>> huh = foo.__class__._.frob
    >>> # huh is the class frob method but is not bound to any class
    >>>        

> Thin ice again I'm on here (even more), but I have the impression
> that creating a class Point in Smalltalk _automatically_ creates two
> classes: Point and PointClass. The latter is normally hidden (but
> contains the class methods of Point as instance methods).

That's the way I remember it too.  And, (if I recall correctly) in
SmallTalk (unlike CLOS), you have no control over the meta-class.  In
the example above, like in SmallTalk, the name of foo.__class__ is
determined automatically.  In this case it is 'foo_class'.  However,
unlike SmallTalk, the above example could be extended to include a
'class __class__:' definition under the existing 'class __class__:'.
The name generated by this construct would, of course, be
'foo_class_class'.  Lather, Rinse, repeat...

--
Donald Beaudry                                     Ab Initio Software Corp.
                                                   201 Spring Street
donb at init.com                                      Lexington, MA 02421
                      ...Will hack for sushi...




More information about the Python-list mailing list