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

[Eric Snow]

On Thu, Jun 7, 2012 at 8:12 AM, Larry Hastings <larry at hastings.org> wrote:
> On 06/06/2012 06:00 PM, Nick Coghlan wrote:
>
>> On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow <ericsnowcurrently at gmail.com>
>> wrote:
>>
>> Furthermore, using __signature__ as a cache may even cause problems.
>> If the Signature object is cached then any changes to the function
>> will not be reflected in the Signature object.  Certainly that's an
>> unlikely case, but it is a real case. [...]
>
> +1
>
>
> I'm missing something here.  Can you give me an example of modifying an
> existing function object such that its Signature would change?  Decorators
> implementing a closure with a different signature don't count--they return a
> new function object.

I doubt there are any but corner cases to demonstrate here.  I'd don't
presume to say what use there may be in changing a function's state.
However, the fact is that a change to any of the following would cause
a cached __signature__ to be out of sync:

* f.__annotations__
* f.__closure__
* f.__code__
* f.__defaults__
* f.__globals__
* f.__kwdefaults__
* f.__name__
* f.__qualname__

All of these are at least replaceable, if not mutable.   If
inspect.signature() is intended for function introspection purposes,
I'd expect it's return value (cached on __signature__ or not) to
reflect the function and not a previous state of the function.  I
prefer the idea that f.__signature__ means it was set explicitly.
Then there's no doubt as to what it's meant to reflect.

>> Providing a defined mechanism to declare a public signature is good,
>> but using that mechanism for implicit caching seems like a
>> questionable idea. Even when it *is* cached, I'd be happier if
>> inspect.signature() returned a copy rather than a direct reference to
>> the original.
>
>
> I'll say this: if we're going down this road of "don't cache Signature
> objects", then in the case of __signature__ we should definitely return a
> copy just for consistency's sakes.  It'd be a miserable implementation if
> signature() sometimes returned the same object and sometimes returned
> different but equivalent objects when called multiple times on the same
> object.

+1

-eric