Let's make it so. On Sat, Jun 23, 2018, 08:53 Terry Reedy <tjre...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
