[Python-3000] rough draft signature PEP

[Talin]

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> > My mental model matches Brett's.
> 
> I think of them as separate things, too. Separate attributes also makes it 
> easier to add additional metadata later, and the structure of each attribute 
> can be well-defined.
> 
> For example, given:
> 
> def f(req:int, opt=val, *args, reqkwd, optkwd=val2, **kwds):
>      pass
> 
> A signature object like the following would then be relatively easy to grasp:
> 
> sig = f.__signature__
> assert sig.required_args == ('req',)
> assert sig.optional_args == ('opt',)
> assert sig.extra_args == 'args'
> assert sig.required_keywords == ('reqkwd',)
> assert sig.optional_keywords == ('optkwd',)
> assert sig.extra_keywords == 'kwds'
> assert sig.defaults == dict(opt=val, optkwd=val2)
> assert sig.argtypes == dict(req=int)

Sounds like I'm out-voted here. All right :)

My only other comment is that I think that the format of the signature attribute
should be use-case driven - that is, we should come up with some example use
cases, implement them in code, and see what kind of signature format is most
convenient for those use cases.

I would suggest the following use cases as sample points within a broader range
of possible uses:

1) trace decorator: Print the names of their arguments and their values before
calling the function.

2) precondition decorator: Allow arbitrary preconditions to be added to specific
parameters.

3) alternative dispatch decorator: Using the signature API, implement an
alternative dispatch method. This could be something as simple as matching
argument names - so if you call "func( a=3 )" it searches for a version of func
that has an argument named 'a'.

-- Talin