Here's something to start the fight ;-) ...

1) What would you do with class methods that you cannot do with e.g. globals and functions ?

I will write up a concrete example I have and post it later. Look into the motivation for the Prototype Pattern in the GOF book, or even better in the discussion of this pattern in the 'Design Pattern Smalltalk Companion' book. This pattern is not needed if classes are 'first class' objects.

2) How would you determine which methods are class-only methods and which are one usable by instances ?

This is one of the issues which has to be resolved. I have no proposal at the moment. (Maybe function attributes can help here?)

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... What I want to avoid is class X(...): .... initialize(X)

My impression is that class methods are not really needed and would only make optimizing Python harder... but that's maybe just me ;-)

Unfortunately not, I fear. Thomas

...

Look into the motivation for the Prototype Pattern in the GOF book, or even better in the discussion of this pattern in the 'Design Pattern Smalltalk Companion' book.

I imagine many of us (including yours truly :-) don't recall that in enough detail and/or don't have the book handy to look it up, so would you please do us a favor and explain this in a bit more detail?

This is a valid request, but please wait for my larger example. I'm referring to this because I have not been good at explaining the things I want... All in all: I'm not really ready to start the fight _now_, I was just looking for some help... Thomas PS: I find it strange that everyone so far seems to be against it.

On Fri, 20 Apr 2001, Thomas Heller wrote:

...

Here's something to start the fight ;-) ...

1) What would you do with class methods that you cannot do with e.g. globals and functions ?

I will write up a concrete example I have and post it later.

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*. Currently, you have to do the ugly hack: class Foo: __class_implements__ = FooFactory # the class implements # FooFactory. 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.

Look into the motivation for the Prototype Pattern in the GOF book, or even better in the discussion of this pattern in the 'Design Pattern Smalltalk Companion' book.

This pattern is not needed if classes are 'first class' objects.

...

2) How would you determine which methods are class-only methods and which are one usable by instances ?

This is one of the issues which has to be resolved. I have no proposal at the moment. (Maybe function attributes can help here?)

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.

...

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...

What I want to avoid is

class X(...): .... initialize(X)

Yes! We use this monstrosity a lot in Zope. -Michel

...

Is someone willing to join me fighting for class methods (I mean 'real' class-methods in the Smalltalk style here, _not_ static methods like in Java or C++).

I will fight class methods to the death. :-) Ouch :-)

Seriously, I think you'll find an ally in Jim Fulton,

So there _is_ some hope.

who basically told me (since he's sort of my boss :-) to get on with this work.

This must be the reason that ExtensionClass provides them: You can implement them in C, and override them in python subclasses. Thomas

...

...

...

...

...

"GvR" == Guido van Rossum 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?

[Barry wrote]

If you use naming to generally distinguish, and have a lookup chain that first found it in C.__dict__ and then looked in M.__dict__, you could control what happens when the name is in both dicts by using a more explicit lookup, e.g. C.__dict__['meth'] vs. C.__class__.__dict__['meth']

Couldn't be C.__class__.meth be used?

But maybe that's too ugly.

GvR> How does Smalltalk resolve this? I'm walking on thin ice here (maybe I should better try it out), but IIRC Smalltalk requires to explicit:

Another question: presumably when I write

class Foo: pass

Foo is implicitly given the built-in metaclass M, but say I wanted to define a class Foo with a different metaclass, how would I spell this? I think at one point I suggested a semi-ugly syntactic hack, where `class' was actually a namespace and you could add new metaclasses to it. So you could write something like

class.WeirdClass Foo: pass

and now Foo's metaclass would be WeirdClass. Thin ice again I'm on here (even more), but I have the impression

self class method; or self method; 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). Thomas

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

Guido:

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? How does Smalltalk resolve this?

The problem doesn't arise in Smalltalk, because method calls and instance variable accesses are completely different things and are handled by quite separate syntaxes and mechanisms. Python creates problems for itself here by confusing instance variables of the class with metadata about the instance's methods, and keeping them both in the same namespace. Thomas Heller :

I'm walking on thin ice here (maybe I should better try it out), but IIRC Smalltalk requires to explicit:

self class method; or self method;

No, to call a class method in Smalltalk, you just send a message to the class itself rather than an instance. There's no difference in the message sending syntax.

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).

Yes. You don't normally get a choice about what the metaclass is, although no doubt you could reach under the covers and manually construct your own metaclass and instantiate it if you wanted. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+