[Python-Dev] Updated PEP 362 (Function Signature Object)

[Yury Selivanov]

Eric,

On 2012-06-07, at 12:54 PM, Eric Snow wrote:
> On Wed, Jun 6, 2012 at 11:10 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> I like the idea of 'foo(a)' and 'bar(a)' having the identical signatures,
>> however, I don't think it's possible.  I.e. we can't make it that the
>> 'signature(foo) is signature(bar)'.  We can implement the __eq__ operator
>> though.
> 
> Adding __eq__ and __ne__ is a good thing.  

We still don't have a good use case for this, though.

> However, I don't care so
> much about the identity/equality relationship as I do about the
> relationship between Signature objects and functions.

Yes, that's the core issue we have - the relation between Signature
objects and functions.

> Regarding name and qualname, several questions:
> 
> * Is the use of qualname in errors part of the PEP or an implementation detail?

It's more of an implementation detail.  And those errors may be not 
that important, after all.  Probably, the 'Signature.bind()' will be 
used in contexts where you have either the function itself, or at 
least its name to catch the BindError and add some context to it.

> * Can name and qualname be None?

There is no explicit check for it in the code.

Given the fact, that we now want ''signature()'' to work with any
callable, it may be that the callable object doesn't have '__name__'
and '__qualname__' attributes (unless we copy them from its __call__,
and that's a doubtful move)

> * If so, do the errors that rely on them still work?

The code will break.

> * What do you get when you pass a lambda to inspect.signature()?

It will work fine, since lambdas are instances of FunctionType.

> Thinking more about this, for me this PEP is more about call
> signatures than about function declaration signatures.  For a call you
> don't need the callable's name (think lambdas).  Having a name and
> qualname attribute communicates that Signature objects are indelibly
> tied to functions.  So I still don't think name and qualname are
> intrinsic attributes to call signatures.

Yes, you're right.  Brett and Larry also leaning towards defining
Signature as a piece of information about the call semantics,
disconnected from the function.

I like this too, it makes everything simpler.

I think we'll modify the PEP today, to drop 'name' and 'qualname' from
Signature, and implement __eq__.

> In the end this is a relatively minor point that does not detract from
> my support of this PEP.  I just think we should strip any superfluous
> details we can now.  Adding things later is easier than taking them
> away.  :)

Thanks :)  You're right, we can add 'name' and 'qualname' later.

> Warning: the following may seem to contradict what I said above.  Take
> it for what it's worth.  Regardless of name/qualname, it may be useful
> to keep a weak reference on the Signature object to the function on
> which it is based, *if any*.  That's not essential to the concept of
> call signatures, but it could still be meaningful for introspection.

I think that maintaining an explicit link between functions and 
signatures (by passing them around together, or just by passing the 
function and calculating signature out of it when needed) in the user 
code is better, than do it implicitly in the Signature.

Let's not overcomplicate it all ;)

> Alternately, let's consider the case where the PEP actually is all
> about introspecting function declarations (rather than call
> signatures).  Then the attributes of a Signature object could just be
> properties exposing the underlying details from the attached
> function/code object.

How about that later, if needed, we'll add another object to 'inspect',
that will have this information about the function, and will also 
have its signature?

-
Yury