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/archive%40mail-archive.com
