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

[Alexandre Zani]

A question regarding the name. I have often seen the following pattern
in decorators:

def decor(f):
    def some_func(a,b):
        do_stuff using f
    some_func.__name__ = f.__name__
    return some_func

What are the name and fully qualified names in the signature for the
returned function? some_func.__name__ or f.__name__?

On Wed, Jun 6, 2012 at 10:02 AM, Eric Snow <ericsnowcurrently at gmail.com> 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?
>
> FWIW, I think this PEP is great and am ecstatic that someone is
> pushing it forward.  :)
>
> -eric
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/alexandre.zani%40gmail.com