Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #89444
| References | <CAFTm5Ru5NbFOtLPoVSPujeakrGawdHXjNkWJOVs1XrvBNnOUOQ@mail.gmail.com> <CAPTjJmqruXnxm=WOF36Kh56hprnxMkHfXKOv8cMasGn-CEusbg@mail.gmail.com> <CAFTm5RuzO4jKZWpoYsexze7w-GVbUDSGQB=J8eAeY0ZDOY-Uow@mail.gmail.com> |
|---|---|
| Date | 2015-04-27 15:30 +1000 |
| Subject | Re: Function decorator having arguments is complicated |
| From | Chris Angelico <rosuav@gmail.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.38.1430112639.3680.python-list@python.org> (permalink) |
(Redirecting to the list - hope you don't mind) On Mon, Apr 27, 2015 at 2:36 PM, Makoto Kuwata <kwa@kuwata-lab.com> wrote: > > > On Mon, Apr 27, 2015 at 12:20 PM, Chris Angelico <rosuav@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
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Function decorator having arguments is complicated Chris Angelico <rosuav@gmail.com> - 2015-04-27 15:30 +1000
csiph-web