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

Eric Snow ericsnowcurrently at gmail.com
Thu Jun 7 02:52:05 CEST 2012


On Wed, Jun 6, 2012 at 11:28 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> Never copy attributes by hand, always use 'functools.wraps'.  It copies
> '__name__', '__qualname__', and bunch of other attributes to the decorator
> object.
>
> We'll probably extend it to copy __signature__ too; then 'signature(decor(f))'
> will be the same as 'signature(f)'.

Having the signature object stored on a function is useful for the
cases like this, where the signature object is *explicitly* set to
differ from the function's actual signature.  That's a good reason to
have inspect.signature(f) look for f.__signature__ and use it if
available.

However, I'm not seeing how the other proposed purpose, as a cache for
inspect.signature(), is useful.  I'd expect that if someone wants a
function's signature, they'd call inspect.signature() for it.  If they
really need the speed of a cache then they can *explicitly* assign
__signature__.

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. If f.__signature__ is set, I'd
expect it to be either an explicitly set value or exactly the same as
the first time inspect.signature() was called for that function.  We
could make promises about that and do dynamic updates, etc., but it's
not useful enough to go to the trouble.  And without the guarantees, I
don't think using it as a cache is a good idea.  (And like I said,
allowing/using an explicitly set f.__signature__ is a good thing).

-eric


More information about the Python-Dev mailing list