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

Yury Selivanov yselivanov.ml at gmail.com
Wed Jun 6 19:10:16 CEST 2012


Eric,

On 2012-06-06, at 1:02 PM, Eric Snow wrote:
> On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> On 2012-06-06, at 11:38 AM, Steven D'Aprano wrote:
>>> Functions already record their name (twice!), and it is simple enough to query func.__name__. What reason is there for recording it a third time, in the Signature object?
>> 
>> Signature object holds function's information and presents it in a
>> convenient manner.  It makes sense to store the function's name,
>> together with the information about its parameters and return
>> annotation.
>> 
>>> Besides, I don't consider the name of the function part of the function's signature. Functions can have multiple names, or no name at all, and the calling signature remains the same.
>> 
>> It always have _one_ name it was defined with, unless it's
>> a lambda function.
>> 
>>> Even if we limit the discussion to distinct functions (rather than a single function with multiple names), I consider spam(x, y, z) ham(x, y, z) and eggs(x, y, z) to have the same signature. Otherwise, it makes it difficult to talk about one function having the same signature as another function, unless they also have the same name. Which would be unfortunate.
>> 
>> I see the point ;)  Let's see what other devs think.
> 
> 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.

For me, the signature of a function is not just a description of its 
parameters, so it seems practical to store its name too.

> FWIW, I think this PEP is great and am ecstatic that someone is
> pushing it forward.  :)


Thanks ;)

-
Yury


More information about the Python-Dev mailing list