[Python-3000] Minor hitch writing the Function Signature PEP

Brett Cannon brett at python.org
Sat Apr 22 23:07:01 CEST 2006


On 4/22/06, Paul Moore <p.f.moore at gmail.com> wrote:
> On 4/22/06, Talin <talin at acm.org> wrote:
> > Well the problem is that decorator functions don't have access to the machinery
> > that binds input arguments for formal parameters. So the wrapper function has a
> > hard time knowing which input arguments will be bound to which formal params,
> > without having to duplicate the runtime's algorithm to do this.
> >
> > In order to be a generic wrapper, the wrapper will have the form:
> >
> > def wrapper( *args, **kwargs ):
> >    ...
> >
> > So where is 'y' in all of that? It could be the second argument in *args; it
> > could be the first argument in *args if x is passed in as a keyword argument; or
> > it could be in the **kwargs dict.
>
> [Wild idea alert!]
>
> Maybe the signature object could have a "bind" method
>
>    sig.bind(args, kwargs)
>
> which returns a dictionary mapping argument names to values? In
> effect, this exposes the internal mechanism for reuse.

I don't see why the signature object has to be created for every
function automatically; I don't see it being a constantly needed
thing.  If something like a signature built-in was created it could be
called on objects as needed to create the signature object as well as
bind it to __signature__ for future use to avoid duplicated work. 
This would allow a decorator to assign to the decorator the signature
object from the wrapped function::

 def decorator(func):
     def wrapper(*args, **kwargs):
         # ... stuff
     wrapper.__signature__ = signature(func)
     return wrapper

Or something along those lines.  I am on vacation right now but I am
still planning on digging up my signature PEP which covers all of
this.

-Brett


More information about the Python-3000 mailing list