[Python-Dev] About .append == .append
Let's make it so.
On Sat, Jun 23, 2018, 08:53 Terry Reedy <tjreedy at udel.edu> wrote:
> 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
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...