Using metaclasses to play with decorators.

Michele Simionato michele.simionato at
Tue Jun 15 11:39:56 CEST 2004

Michael Sparks <zathras at> wrote in message news:<mailman.958.1087257261.6949.python-list at>...
> [ I'm not really sure of the etiquette of the python-dev list, so I think
>   I'll play "safe" and post this thought here... I know some of the
>   developers do look here, and Guido's comment (before europython) on the
>   dev list saying he's not interested in new syntaxes makes me think this
>   is a better place for it... ]
> Anyway...
> At Europython Guido discussed with everyone the outstanding issue with
> decorators and there was a clear majority in favour of having them, which
> was good. From where I was sitting it looked like about 20:20 split on the
> following syntaxes:
> 1    def func(arg1, arg2, arg3) [dec,dec,dec]:
>         function...
> 2    [dec,dec,dec] def func(arg1, arg2, arg3):
>         function...
> When it came to the decision on whether 2.4 includin one of these two
> options or a waiting for a third unspecified, indeterminate syntax in a
> later version, it looked like around a 60:40 vote in favour of waiting.
> (ie 60:20:20 for waiting/syntax 1/syntax 2)
> <snip>

The problem of metaclasses-based solutions is that they are hacks.
We don't want everybody to implement his/her version of decorators
(yes me too I have implemented mine). Decorators MUST be in the core 
language. Waiting will only favor the abuse of metaclasses.
I do not particularly like each of two syntaxes (even if the second
one looks better) but also I do not particularly dislike them.
My preferred solution would be 

def func(...) is dec:

*without* the ability to specify multiple decorators (i.e. let compose
the multiple generators explicitely by hand, with a functional.compose 
function or something like that). 

But I prefer to have a syntax I don't like 100% then waiting for another
year or so. Why don't put a given syntax in 2.4a, see how it goes, and
change it in 2.4b if it is the case?

                 Michele Simionato

More information about the Python-list mailing list