Guido van Rossum wrote: > On 4/30/06, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Nick Coghlan wrote: >> > Collin Winters has done the work necessary to rename PEP 309's functional >> > module to functools and posted the details to SF [1]. >> > >> > I'd like to take that patch, tweak it so the C module is built as >> > _functools >> > rather than functools, and then add a functools.py consisting of: >> >> I'm all for it. (You could integrate the C version of "decorator" from my SF >> patch, but I think Python-only is enough). > > Stronger -- this should *not* be implemented in C. There's no > performance need, and the C code is much harder to understand, check, > and modify.
+1. > I expect that at some point people will want to tweak what gets copied > by _update_wrapper() -- e.g. some attributes may need to be > deep-copied, or personalized, or skipped, etc. What exactly do you have in mind there? If someone wants to achieve this, she can write his own version of @decorator. One thing that would be nice to copy is the signature, but for that, like demonstrated by Simon Belak, exec trickery is necessary, and I think that's one step too far. The basic wish is just to let introspective tools, and perhaps APIs that rely on function's __name__ and __doc__ work flawlessly with decorators applied, nothing more. > (Doesn't this already > apply to __decorator__ and __decorates__? I can't prove to myself that > these get set to the right things when several decorators are stacked > on top of each other.) I don't think they're necessary. > I'm curious if @decorator is the right name and the right API for this > though? The name is overly wide (many things are decorators but should > not be decorated with @decorator) and I wonder of a manual call to > _update_wrapper() wouldn't be just as useful. Still, _update_wrapper would need to be defined somewhere, and it would have to be called in the body of the decorator. > (Perhaps with a simpler > API -- I'm tempted to call YAGNI on the __decorator__ and > __decorates__ attributes.) > > I think there are too many design options here to check this in > without more discussion. So let the discussion begin! Georg _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
