(Redirecting to the list - hope you don't mind) On Mon, Apr 27, 2015 at 2:36 PM, Makoto Kuwata <k...@kuwata-lab.com> wrote: > > > On Mon, Apr 27, 2015 at 12:20 PM, Chris Angelico <ros...@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 -- https://mail.python.org/mailman/listinfo/python-list