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 <ericsnowcurren...@gmail.com> wrote:
> On Wed, Jun 6, 2012 at 10:20 AM, Yury Selivanov <yselivanov...@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@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/alexandre.zani%40gmail.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
