[Python-Dev] Updated PEP 362 (Function Signature Object) (original) (raw)
Eric Snow ericsnowcurrently at gmail.com
Thu Jun 7 18:54:15 CEST 2012
- Previous message: [Python-Dev] Updated PEP 362 (Function Signature Object)
- Next message: [Python-Dev] Updated PEP 362 (Function Signature Object)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Jun 6, 2012 at 11:10 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
On 2012-06-06, at 1:02 PM, Eric Snow wrote:
I'm with Steven on this one. What's the benefit to storing the name or qualname on the signature object? That ties the signature object to a specific function. If you access the signature object by f.signature then you already have f and its name. If you get it by calling signature(f), then you also have f and the name. If you are passing signature objects for some reason and there's a use case for which the name/qualname matters, wouldn't it be better to pass the functions around anyway? What about when you create a signature object on its own and you don't care about the name or qualname...why should it need them? Does Signature.bind() need them? Yes, 'Signature.bind' needs 'qualname' for error messages. But it can be stored as a private attribute. 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. However, I don't care so much about the identity/equality relationship as I do about the relationship 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?
- Can name and qualname be None?
- If so, do the errors that rely on them still work?
- What do you get when you pass a lambda to inspect.signature()?
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.
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. :)
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.
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.
And finally, keep up the good work!
-eric
- Previous message: [Python-Dev] Updated PEP 362 (Function Signature Object)
- Next message: [Python-Dev] Updated PEP 362 (Function Signature Object)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]