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

Nick Coghlan ncoghlan at gmail.com
Fri Jun 8 03:24:45 CEST 2012


On Fri, Jun 8, 2012 at 4:34 AM, Larry Hastings <larry at hastings.org> wrote:
> In other words: this is possible but extremely unlikely, and will only be
> done knowingly and with deliberate intent by a skilled practitioner.
>
> I think it's reasonable to declare that, if you're monkeying around with
> dunder attributes on a function, it's up to you to clear the f.__signature__
> cache if it's set.  Like Spiderman's uncle Cliff Robertson said: with great
> power comes great responsibility.
>
> I am now firmly in the "using __signature__ as a cache is fine, don't make
> copies for no reason" camp.

I have a simpler rule: functions in the inspect module should not have
side effects on the objects they're used to inspect.

When I call "inspect.signature(f)", I expect to get something I can
modify without affecting the state of "f". That means, even if
f.__signature__ is set, the signature function will need to return a
copy rather than a direct reference to the original. If
f.__signature__ is going to be copied *anyway*, then there's no reason
to cache it, *unless* we want to say something other than what the
inspect module would automatically derive from other attributes like
__func__, __wrapped__, __call__, __code__, __closure__, etc.

There are lots of ways that implicit caching can go wrong and fail to
reflect the true state of the system, and unlike a centralised cache
such as linecache or those in importlib, a distributed cache is hard
to clear when the state of the system changes. If "signature creation"
ever proves to be a real bottleneck in an application, then it is free
to implement it's own identity-based cache for signature lookup.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list