[Python-Dev] decorator support (original) (raw)

Edward Loper edloper at gradient.cis.upenn.edu
Sun Sep 5 20:17:31 CEST 2004

Raymond wrote:

So, it would be nice if there were some support for carrying forward the argspec to inform help(), calltips(), and inspect().

+1. I've already gotten one complaint about decorators confusing epydoc (since the user wasn't copying the function's name), and I expect to get many more. One thing that's always bothered me about classmethod and staticmethod is the fact that you can't inspect them.
Compare that to instancemethod, which has the im_func property.

One way to carry forward the argspec would be to recommend that decorators add a pointer back to the undecorated function (similar to instancemethod's im_func):

newf.doc = oldf.doc # copy the docstring newf.dict.update(oldf.dict) # copy attributes newf.name = oldf.name # keep the name (new in Py2.4) newf.undecorated = oldf # [XX NEW] ptr to undecorated obj

Then tools like pydoc/epydoc could be written to check this property for the real argspec. (Note that there's precedent for showing the undecorated signature in tools like pydoc/epydoc, since that's what they both do with instancemethods, classmethods, and staticmethods).

We would want to pick a standard name. undecorated seems reasonable to me, but I'd be ok with other names.

Martin v. Lowis wrote:

What were you thinking of? I could imagine a predefined class, such as class copyfuncattrs: [...]

This function could take care of adding the undecorated attribute.
But I'm not sure copyfuncattrs is the right name; note that it works just as well on class decorators (we did decide that we're allowing those, right?). Perhaps just copyattrs?

Martin v. Lowis wrote:

Then, the question is where copyfuncattrs should live, and I would object that to be yet another builtin.

Having trouble parsing this sentence -- do you mean that you object to making it a builtin, or did you mean "I would expect that to be..."?

Anthony Baxter wrote:

I think it's very likely that in 2.5 we'll have some sort of 'decorators' module that captures these sorts of things. I don't think it's likely we'll know enough about the various ins and outs of decorators to want to put something in 2.4.

I disagree. We may not know much about the ins and outs of decorators, but I feel very confident that I'll want to be able to inspect them, whatever they are. I would very much like for one of the following to happen before we release 2.4:

(I can write up an appropriate patch for the docs if no one objects; for copyfuncattrs, we'd need to decide what to name it and where it should live, first.)

-Edward

More information about the Python-Dev mailing list