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

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