Jim Jewett wrote:

Josiah Carlson:

...

I just noticed that decoration of classes was not included with the @decoration syntax that made it into Python 2.4. ...

...

Is the fact that it didn't make it into 2.4 due to a pronouncement

Yes, but it wasn't a permanent decision, and I don't think he used the magic word "pronounce".

Adding class decoration later is not difficult.

Retracting class decoration later would have been impossible.

Therefore Guido decided for version 2.4, but left the question open for the unspecified future. Changing it would take arguments stronger than symmetry or "why not?", so it probably won't change for 2.5, but if you have a compelling use case ...

(Mine have all been using an object as a callable -- basically replacing a function. The itch hasn't been strong enough to bother me.)

I think of it like this; I learned restructured text because I wanted to learn a markup for writing things that didn't encumber the writing. At a certain point, it became necessary for me to learn TeX. Does that mean that reST has no use to me now that I know TeX? Of course not, reST still has its place, and when I write documentation, I write it in reST. When I begin to write academic papers, I write it in reST, then later translate it to TeX, because that is the language of typeset academic writings. I could write it first in TeX, but the notation can get cumbersome, and reST is still valid (whether or not it survives the decade; I still have the source, a python interpreter, and an emulator). While I have not used it often, I have done the equivalent of decorating classes; it is as natural (though perhaps not quite as useful initially) as decorating functions, and as simple as writing in reST. I also happen to know a bit about using metaclasses, though tend to shy away from it, because it feels cumbersome. Can you do everything with TeX that you can with reST? Of course. Does it make reST any less valid or desireable to use? Of course not. Can you use a metaclass to do anything you could do with class decorators? Probably (I don't know the corner cases that would make it not so). Does that mean that class decoration is any less valid or desireable to use? Of course not. Does that mean that it should have a syntax? That is the question. I personally choose class decoration over metaclasses (when possible) because I feel it is easier to use. However, as my use case has not been compelling enough in the past, I is certainly not compelling enough now. If someone cares more about this, who has more influence and wants to continue the conversation; feel free, but I'll still use Python tomorrow without class decoration syntax. - Josiah P.S. You know, it's kind of like putting sprinkles on a banana split. Some people like the sprinkles, some people don't. Some people complain when they are there, some people can't eat it without the sprinkles. But you know what? You've got the banana split already, enjoy it. If you get the sprinkles, so be it, but hassling the waitress for sprinkles is a pretty rude thing to do to a woman in an ice cream parlor.

Eric Nieuwland wrote:

Given the ideas so far, would it possible to:

def meta(cls): ...

@meta class X(...): ...

It is not implemented in Python 2.4. From what I understand, making it happen in Python 2.5 would not be terribly difficult. The question is about a "compelling use case". Is there a use where this syntax is significantly better, easier, etc., than an equivalent metaclass? Would people use the above syntax if it were available? What would you use the above syntax to do? - Josiah

On Sat, 26 Mar 2005 22:49:33 +0100, Eric Nieuwland wrote:

On 26 mrt 2005, at 21:36, Josiah Carlson wrote:

...

Eric Nieuwland wrote:

...

Given the ideas so far, would it possible to:

def meta(cls): ...

@meta class X(...): ...

It is not implemented in Python 2.4. From what I understand, making it happen in Python 2.5 would not be terribly difficult. The question is about a "compelling use case". Is there a use where this syntax is significantly better, easier, etc., than an equivalent metaclass? Would people use the above syntax if it were available?

What would you use the above syntax to do?

Well, I can imagine using

@meta(MyMetaClass) class MyClass(...): ...

instead of

class MyClass(...): __metaclass__ = MyMetaClass ...

Somehow, it seems more aesthetic to me.

This doesn't quite work the same, though. The former creates a new instance of ClassType, then (presumably) rips it apart and passes the pieces to MyMetaClass. The latter just passes the pieces to MyMetaClass unassembled. I can imagine cases where the class creation would fail during the first step of the former process, so I don't think this is actually a use-case for class decorators. Jp

At 07:55 PM 3/28/05 -0500, Jack Diederich wrote:

For compelling, I think the code smell put off by the "no conflict" metaclass generator recipe (which also appeared in Alex Martelli's PyCon talk) is fairly compelling from a duck typing point of view.

# would you rather class K: __metaclass__ = no_conflict(MetaA, MetaB) # or @decoA @decoB class K: pass

Actually, it's possible today with: class K: decoB() decoA() As long as decoA() and decoB() use the "class advisor" mechanism I built for Zope and PyProtocols. That mechanism basically sticks a custom __metaclass__ into the enclosing class, and implements a simple protocol for chaining subsequently-defined class advisors. See 'protocols.advice' in PyProtocols or 'zope.interface.advice' in Zope or Twisted for details. Anyway, I'm not certain that moving these functions up to decorator status will really do anything useful; you can already put them near the top of the class definition, such that they're relatively prominent.