[Python-Dev] Adding functools.decorator

Brett Cannon brett at python.org
Mon May 1 02:31:49 CEST 2006


On 4/30/06, Guido van Rossum <guido at python.org> 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. (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'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.

I am +0 on the manual call.  Just seems like I would like to happen
explicitly instead of through a decorator.

> (Perhaps with a simpler
> API -- I'm tempted to call YAGNI on the __decorator__ and
> __decorates__ attributes.)
>

This should also be redundant once I get the signature PEP cleaned up
(and probably email py3k or python-dev on the subject) since I plan to
store a reference to the function the object represents.  That would
mean if update_wrapper() copies the signature object over then you
have a reference to the original function that way.

-Brett

> I think there are too many design options here to check this in
> without more discussion.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>


More information about the Python-Dev mailing list