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

[Eric Snow]

On Wed, Jun 6, 2012 at 11:10 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> On 2012-06-06, at 1:02 PM, Eric Snow wrote:
>> I'm with Steven on this one.  What's the benefit to storing the name
>> or qualname on the signature object?  That ties the signature object
>> to a specific function.  If you access the signature object by
>> f.__signature__ then you already have f and its name.  If you get it
>> by calling signature(f), then you also have f and the name.  If you
>> are passing signature objects for some reason and there's a use case
>> for which the name/qualname matters, wouldn't it be better to pass the
>> functions around anyway?  What about when you create a signature
>> object on its own and you don't care about the name or qualname...why
>> should it need them?  Does Signature.bind() need them?
>
> Yes, 'Signature.bind' needs 'qualname' for error messages.  But it can be
> stored as a private attribute.
>
> 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.  However, I don't care so
much about the identity/equality relationship as I do about the
relationship 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?
* Can name and qualname be None?
* If so, do the errors that rely on them still work?
* What do you get when you pass a lambda to inspect.signature()?

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.

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.  :)

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.

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.

And finally, keep up the good work!

-eric