[Python-Dev] Re: method decorators (PEP 318) (original) (raw)

Alex Martelli aleaxit at yahoo.com
Sun Mar 28 06:06:12 EST 2004

On 2004 Mar 28, at 04:03, Robert Mollitor wrote: ...

def foopublishtoweb("http://directory/directory"): It would be nice if transformer decorations were never allowed "arguments". It would keep that list as short and as tidy as possible. -1. Forcing what should naturally be arguments to decorators into attributes of the function object would be extremely awkward and risky.

def foo [bar, baz] (a, b , c): @mystery = 23

this is totally unreadable, with no hints whatsoever of whether foo.mystery affects bar, baz, neither, or BOTH -- the latter possibility is an accident waiting to happen, i.e. a programmer knowing that bar uses foo.mystery and not having studied baz enough to gauge that IT, too, will cue on foo.mystery if it's defined. If one wants to keep the list short and tidy (slightly less of an issue if the decorators went right before the : , my preferred syntax) might be something like:

mybar = bar(mystery=23) mybaz = baz(mystery=45)

def foo [mybar, mybaz] (a, b, c): ...

in preference to:

def foo [bar(mystery=23), baz(mystery=45)] (a, b, c): ...

Not ideal, but IMHO still beats by a mile the alternative of having bar and baz cue off the function's attributes, and quite possibly tripping on each other's feet.

I think that, while often the stylistically preferable choice will be to assign identifiers to the results of "metadecorators which produce decorators when called with suitable keyword arguments" (rather than using the metadecorator-call expression right in the decorators list), forcing the issue by prohibiting expressions in the decorators list and mandating only identifiers there is still an inferior design choice.
Python already has a slight issue with having to "compute things beforehand and assign a name to the result" -- rather than leaving the option of an inline expression -- in such cases as function objects (given lambda's limits); in that case, there are enough problems with removing the limitation to make it understandable. But extending the limitation to this case, purely for forcing the stylistic hand of Python programmers, would appear rather arbitrary and ill-advised to me. The fact that it would encourage the problematic usage of relying on function attributes in lieu of decorator arguments seems to me to underline this ill-advisedness strongly.

Alex

More information about the Python-Dev mailing list