On 4/22/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 4/22/06, Talin <[EMAIL PROTECTED]> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
