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

[Larry Hastings]

On 06/06/2012 08:38 AM, Steven D'Aprano wrote:
> What's the fully qualified name of the function, and why is it needed?

Please see PEP 3155.


> "args" is just a common name for the parameter, not for the kind of 
> parameter. *args (or *data, *whatever) is a varargs parameter, and so 
> the attribute should be called "is_varargs".
> [...]
> Likewise for **kwargs (or **kw, etc.)

Yury will be pleased; those were his original names.  I argued for 
"is_args" and "is_kwargs".

I assert that "args" and "kwargs" are not merely "common name[s] for the 
parameter[s]", they are The Convention.  Any seasoned Python programmer 
examining a Signature object who sees "is_args" and "is_kwargs" will 
understand immediately what they are.  Jamming "var" in the middle of 
these names does not make their meaning any clearer--in fact I suggest 
it only detracts from readability.


> Is there a use-case for is_implemented?

Yes, see issue 14626.


> What happens when the existing function metadata and the __signature__ 
> object disagree?
>
> Are there use-cases where we want them to disagree, or is disagreement 
> always a sign that something is broken?
> [...]
> "Changes to the Signature object, or to any of its data members,
> do not affect the function itself."
>
> which leaves the possibility that __signature__ may no longer match 
> the actual argument spec, for some reason. If you remove 
> getfullargspec, people will have to reinvent it to deal with such cases.

There's no reason why they should disagree.  The "some reason" would be 
if some doorknob decided to change it--the objects are mutable, because 
there's no good reason to make them immutable.

We just wanted to be explicit, that information flowed from the callable 
to the Signature and never the other way 'round.

As for "what would happen", nothing good.  My advice: don't change 
Signature objects for no reason.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120606/21e5b78b/attachment-0001.html>