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

Yury Selivanov yselivanov.ml at gmail.com
Thu Jun 7 20:14:22 CEST 2012

Eric,

On 2012-06-07, at 12:54 PM, Eric Snow wrote:

On Wed, Jun 6, 2012 at 11:10 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

I like the idea of 'foo(a)' and 'bar(a)' having the identical signatures, however, I don't think it's possible. I.e. we can't make it that the 'signature(foo) is signature(bar)'. We can implement the eq operator though. Adding eq and ne is a good thing.

We still don't have a good use case for this, though.

However, I don't care so much about the identity/equality relationship as I do about the relationship between Signature objects and functions.

Yes, that's the core issue we have - the relation between Signature objects and functions.

Regarding name and qualname, several questions:

* Is the use of qualname in errors part of the PEP or an implementation detail?

It's more of an implementation detail. And those errors may be not that important, after all. Probably, the 'Signature.bind()' will be used in contexts where you have either the function itself, or at least its name to catch the BindError and add some context to it.

* Can name and qualname be None?

There is no explicit check for it in the code.

Given the fact, that we now want ''signature()'' to work with any callable, it may be that the callable object doesn't have 'name' and 'qualname' attributes (unless we copy them from its call, and that's a doubtful move)

* If so, do the errors that rely on them still work?

The code will break.

* What do you get when you pass a lambda to inspect.signature()?

It will work fine, since lambdas are instances of FunctionType.

Thinking more about this, for me this PEP is more about call signatures than about function declaration signatures. For a call you don't need the callable's name (think lambdas). Having a name and qualname attribute communicates that Signature objects are indelibly tied to functions. So I still don't think name and qualname are intrinsic attributes to call signatures.

Yes, you're right. Brett and Larry also leaning towards defining Signature as a piece of information about the call semantics, disconnected from the function.

I like this too, it makes everything simpler.

I think we'll modify the PEP today, to drop 'name' and 'qualname' from Signature, and implement eq.

In the end this is a relatively minor point that does not detract from my support of this PEP. I just think we should strip any superfluous details we can now. Adding things later is easier than taking them away. :)

Thanks :) You're right, we can add 'name' and 'qualname' later.

Warning: the following may seem to contradict what I said above. Take it for what it's worth. Regardless of name/qualname, it may be useful to keep a weak reference on the Signature object to the function on which it is based, if any. That's not essential to the concept of call signatures, but it could still be meaningful for introspection.

I think that maintaining an explicit link between functions and signatures (by passing them around together, or just by passing the function and calculating signature out of it when needed) in the user code is better, than do it implicitly in the Signature.

Let's not overcomplicate it all ;)

Alternately, let's consider the case where the PEP actually is all about introspecting function declarations (rather than call signatures). Then the attributes of a Signature object could just be properties exposing the underlying details from the attached function/code object.

How about that later, if needed, we'll add another object to 'inspect', that will have this information about the function, and will also have its signature?

More information about the Python-Dev mailing list