On Fri, Jun 8, 2012 at 4:34 AM, Larry Hastings <la...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
