(original) (raw)
On 06/06/2012 06:00 PM, Nick Coghlan wrote:On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow <ericsnowcurrently@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.
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.
/arry