Function decorator having arguments is complicated

[Chris Angelico]

(Redirecting to the list - hope you don't mind)

On Mon, Apr 27, 2015 at 2:36 PM, Makoto Kuwata <kwa at kuwata-lab.com> wrote:
>
>
> On Mon, Apr 27, 2015 at 12:20 PM, Chris Angelico <rosuav at gmail.com> wrote:
>>
>>
>> I agree it would be nice to have extra parameters directly handled,
>> but before you go further with the proposal, I suggest having a read
>> of the original PEP that introduced decorators:
>>
>> https://www.python.org/dev/peps/pep-0318/
>>
>
> Thanks, it is an useful link.
> But I can't find any sentence related to the problem what I argued.

Correct, it doesn't specifically say you can't propose this; I'm just
saying it's good to know how we got here before proposing to go
further.

> I found the following example code in PEP318:
>
>> def accepts(*types):
>>     def check_accepts(f):
>>         assert len(types) == f.func_code.co_argcount
>>         def new_f(*args, **kwds):
>>             for (a, t) in zip(args, types):
>>                 assert isinstance(a, t), \
>>                        "arg %r does not match %s" % (a,t)
>>             return f(*args, **kwds)
>>         new_f.func_name = f.func_name
>>         return new_f
>>     return check_accepts
>
> But nobody seems to mention the complication of the above code.
>
>
>>
>> There are a *lot* of different ways that decorators could have been
>> done. Currently, decorators use a restricted subset of expression
>> syntax; the bit after the @ is guaranteed [1] to be a valid expression
>> which results in a callable which is passed one argument (the
>> function) and whose return value replaces the function. What you
>> propose would no longer be a valid expression, and may introduce
>> parsing problems for the interpreter and/or for humans.
>
>
> Do you mean that it is too difficult to extend python syntax?

Yes; not impossible, but any change to syntax has to be very strongly justified.

>> But if the writing of decorators is hard and common for you, you can
>> always use a bit of metaprogramming to simplify it.
>
>
> It is not so hard for me to read/write complicated decorator,
> but it is hard for young Python programmer those who I'm teaching Python.
> (And it is hard for me to explain them about complicated decorator.)
>
> It would be very good for both me and young Python programmer
> if decorator having arguments could be described in non-complicated code.
>
> # Meta decorator programming is not the solution I hope.
> # It introduces another complex.

Maybe, but you could just give your students a black-box module that
makes life easier for them - the "modify" or "decorator" function
could be in there.

Or you could do what I do with my students, and simply start from the
simplest decorators and build up. It's usually not hard to describe a
simple hard-coded decorator (always does the same thing), then a
simple wrapping decorator (calls the original function, returns a
wrapper), and then add parameters after that.

ChrisA