[Python-Dev] pep 362 - 5th edition

[Yury Selivanov]

On 2012-06-19, at 1:03 PM, Ethan Furman wrote:

> 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?

Well, it doesn't have much of an API right now (just few methods)

-
Yury