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

[Alex Martelli]

On 2004 Mar 28, at 04:03, Robert Mollitor wrote:
    ...
>> def foo[publish_to_web("http://directory/directory")](self):
>
> 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