[Python-Dev] Class Methods

[Dieter Maurer]

Michel Pelletier <michel at digicool.com> writes on Fri, 20 Apr 2001 10:50:15 -0700 (PDT):
> There are a number of reasons why I'm all for Class attributes in general.
> For example, right now a class object cannot assert an interface.  Sure,
> a class can say:
> 
> class Foo:
> 
>   __implements__ = Bar  # instances implement Bar
> 
> but that is an assertion for the instances, not the *class itself*.
I do not understand that.
What should "assertion about the class itself" mean?

Up to now, I viewed a class as an abstraction of its instances.
If something is true about all its instances, I can say it is
true for the (complete) class -- via this same abstraction.

As long as classes support essentially only one operation:
instantiation, this seems to be justified.

By the way, "__implements__ = Bar" alone is not an assertion
but an assignment, at best a declaration.

> Currently, you have to do the ugly hack:
> 
> class Foo:
> 
>   __class_implements__ = FooFactory # the class implements
>                                     # FooFactory.
At least I do not understand the difference between
"__implements__=" and "__class_implements__=".

> We've done things like the above in several places in our underground
> component elaboration.  Not having class methods introduces many little
> wrinkles in the Python object model that have to be worked around.  I can
> imagine, for example, wanting to define an __reduce__, or __init__ for a
> class object, which is not possible now.
What would be their semantics?

> I always thought along the lines of saying Class.instanceAttribute('foo')
> in the place of what is now said Class.foo.  This would, of course, break
> code, but the warning and back to the future features mitigate most of
> that risk.
What about a new access syntax for the new feature, the class attributes,
and leave the access syntax for the old feature unchanged?

	Class.__classAttribute__(....)

Use "__future__" only if really necessary.

> > > 3) If you don't like globals (see 1), wouldn't it be possible to
> > >    store the state you want to manipulate using class methods
> > >    in some other context object ?
> > I want the class methods (for example) to create and manipulate
> > this 'context object'. This object, however, belongs into the class...
Can't you do that right now?

> > What I want to avoid is
> >
> >   class X(...):
> >       ....
> >   initialize(X)
> 
> Yes! We use this monstrosity a lot in Zope.
You know Guido's MetaClass article?

I read it (did not understand it completely) and
I think, automatic initialization at the end of
class construction would be feasible.



Dieter