> On Nov 18, 2019, at 19:34, Brendan Barnwell <brenb...@brenbarn.net> wrote: > > > I would say this is a poor design. Just write "wait" so that you always > have to call it, and you just pass no arguments if you want the default. > So instead of this: > > # default delay > @wait > def foo(): > > # custom delay > @wait(2) > def foo(): > > . . . you do this: > > # default delay > @wait() > def foo(): > > # custom delay > @wait(2) > def foo():
The only problem with this is the error handling. If you don’t check the type of the argument in wait, this isn’t an error: @wait def foo(spam): … and neither is calling the returned function with a single argument. If you call the value returned by _that_ function, you’ll get a TypeError, but you’re not going to do that. You’re just going to see that instead of waiting a second and doing some side effects, foo returns immediately having done nothing, and then have to debug that. Obviously this is the same bug as writing print on a line by itself instead of print(), or lambda dummy: frob instead of lambda dummy: frob(), etc. But the fact that so many decorators actually do make @foo and @foo() do the same thing raises the expectation that other decorators will do the same. (And because the error is two levels down, it’s harder to debug.) Maybe that means we need to put one of those nice helper tools that make it trivial to write a @foo that behaves that way into the stdlib. Or just mention how to do (and that helpers are readily available) in the docs on decorators. (I don’t think it means we need to add a whole new decorator syntax that just does that for you magically but is otherwise the same as the existing one.) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GGH7S66CE6CQ35CRWWMWNGBLPHUDSGGN/ Code of Conduct: http://python.org/psf/codeofconduct/