[Python-Dev] About .append == .append
tjreedy at udel.edu
Sat Jun 23 11:51:18 EDT 2018
On 6/23/2018 4:54 AM, Serhiy Storchaka wrote:
> 23.06.18 10:27, Jeroen Demeyer пише:
>> On 2018-06-23 03:50, Steven D'Aprano wrote:
>>> I think it is more important that builtin methods and Python methods
>>> behave the same.
>> This inconsistency is the *real* problem here. It's one little extra
>> complication to merging those classes (which was proposed in PEP 575,
>> 576 and 579).
> +1 too. But I think the right solution should be opposite: reverting
> issue1350060 changes and making all methods equality be based on the
> identity of __self__.
We 3, and Armin Rigo, it appears, agree that equivalent C and Python
coded functions should act the same in comparisons. Abstractly, in
English, one might say that a.m equals b.m is true if they perform the
same action and have the same effect.
The problem, even after adding a stipulation of same type, is that the
nature of 'action and effect' are different for pure function methods
versus mutation methods. Since pure functions ignore the identify of a
and b, so should a.pure_func == b.pure_func. a == b is the right test.
For example, a.bit_length == b.bit_length should be true, not false, if
a == b. On the other hand, identify is essential for mutation methods,
so 'a is b' is the right test, as for .append.
But without functions having an 'I mutate' flag, '==' cannot know which
comparison of a and b to use, so we have to choose one, and the choice
should not depend on the coding language. 'a == b' leads to false
positives; 'a is b' leads to false negatives. I don't know how method
comparison is actually used, if ever, but false negatives seem safer to
me. So I currently agree with Serhiy's choice.
Terry Jan Reedy
More information about the Python-Dev