Function decorator having arguments is complicated
rosuav at gmail.com
Mon Apr 27 07:30:36 CEST 2015
(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:
> 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
> 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  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.
More information about the Python-list