[Python-Dev] Class Methods

[Michel Pelletier]

On Fri, 20 Apr 2001, Guido van Rossum wrote:

> Let x be an object, C its class, and M C's class.  So,
>
>   x.__class__ is C
>   C.__class__ is M
>
> Then x's methods are described in C.__dict__, and C's methods are
> described in M.__dict__.
>
> The problem is that if you write C.spam, there could be two spams: one
> in C.__dict__, one in M.__dict__.  Which one to use?

I think, at the expense of breaking code, M.

> How does
> Smalltalk resolve this?  The problem is that for backwards
> compatibility, at lease, C.spam must be the unbound version of x.spam,
> because currently x.spam(...) can always also be written as
> C.spam(x, ...).

This is the part that choosing M would break.  To get at C's shared
instance attributes you could say something like
C.instanceAttribute('spam')(x, ...).

Yes, it's ugly.  Perhaps someone can think of a more elegant spelling?

> For regular methods it may be possible to avoid this simply by
> choosing non-conflicting names, but I seem to recall that Jim wanted
> to use class methods with certain special names (like __init__ or
> __getattr__?), and I have no idea how to do this without dropping the
> idea that x.spam(...) is C.spam(x, ...).  So maybe that's the
> solution?

I'm not sure which idea you are talking about dropping, the first argument
binding behavior, or the spelling of getting shared instance attributes
from a class (C.spam).  Just asking to make sure, cuz I don't think the
first needs to change, just the spelling.

BTW, you sent me some comments on the Components and Interfaces chapter
of the Zope Developer's Guide where you noted that attributes of interface
objects are not the attributes described by the interface and that this is
"unfamiliar to the typical python programmer", ie:

  interface Hello:

    def hello(name):
      """ say hello to a name """

does not create a 'Hello.hello'.  Instead, you need to say
"Hello.getDescriptionFor('hello')".  If we chose the more familiar
'Hello.hello' then the interface interface would be seriously limited, and
any added functionality would need to be imported from an external module
or be a builtin like isinstance().  Interfaces, like classes, wouldn't be
able to have their own methods.

-Michel