[Python-Dev] About [].append == [].append

[Terry Reedy]

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.
>>
>> +1
>>
>> 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