Using metaclasses to play with decorators.
Michele Simionato
michele.simionato at poste.it
Tue Jun 15 05:39:56 EDT 2004
Michael Sparks <zathras at thwackety.com> wrote in message news:<mailman.958.1087257261.6949.python-list at python.org>...
> [ 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