[Python-Dev] pep 362 - 5th edition

[Ethan Furman]

Yury Selivanov wrote:
> On 2012-06-19, at 11:55 AM, Ethan Furman wrote:
> 
>> Yury Selivanov wrote:
>>> Hello,
>>> The new revision of PEP 362 has been posted:
>>> http://www.python.org/dev/peps/pep-0362/
>>> Summary:
>>> 1. What was 'Signature.__deepcopy__' is now 'Signature.__copy__'.
>>> __copy__ creates a shallow copy of Signature, shallow copying its
>>> Parameters as well.
>>> 2. 'Signature.format()' was removed.  I think we'll add something
>>> to customize formatting later, in 3.4.  Although, Signature still has
>>> its __str__ method.
>>> 3. Built-in ('C') functions no longer have mutable '__signature__'
>>> attribute, that patch was reverted.  In the "Design Considerations"
>>> section we stated clear that we don't support some callables.
>>> 4. Positions of keyword-only parameters now longer affect equality
>>> testing of Signatures, i.e. 'foo(*, a, b)' is equal to 'foo(*, b, a)'
>>> (Thanks to Jim Jewett for pointing that out)
>>> The only question we have now is:  when we do equality test between
>>> Signatures, should we account for positional-only, var_positional
>>> and var_keyword arguments names?  So that: 'foo(*args)' will
>>> be equal to 'bar(*arguments)', but not to 'spam(*coordinates:int)'
>>> (Again, I think that's a Jim's idea)
>> There are obviously cases where the names should be considered (such as foo(source, dest) and bar(dest, source) ) and cases where it should not be (spam(text, count) and eggs(txt, cnt) )...
>>
>> I think the default implementation should be strict (names are considered) as it is safer to have a false negative than a false positive.
> 
> +1
> 
>> However, rather than force everyone who is willing to cope with the possible false positives from rewriting a Signature equality routine that ignores names, perhaps a method can be added to the class that does so?
>>
>> class Signature:
>>   . . .
>>   def equivalent(self, other):
>>      "compares two Signatures for equality (ignores parameter names)"
>>      . . .
> 
> I don't think that comparing signatures will be a common operation,
> so maybe we can postpone adding any additional methods for that?

Sure, toss it in the list of possible adds for 3.4.

At some point it was suggested that Signature be put in provisionally so 
we could modify the API if needed -- are we doing that?

~Ethan~