[Python-Dev] Adding functools.decorator

Georg Brandl g.brandl at gmx.net
Sun Apr 30 19:09:29 CEST 2006

Guido van Rossum wrote:
> On 4/30/06, Georg Brandl <g.brandl at gmx.net> 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.


> 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!


More information about the Python-Dev mailing list