On Thu, Jun 7, 2012 at 8:12 AM, Larry Hastings <la...@hastings.org> wrote: > On 06/06/2012 06:00 PM, Nick Coghlan wrote: > >> On Thu, Jun 7, 2012 at 10:52 AM, Eric Snow <ericsnowcurren...@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 _______________________________________________ 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
