New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cross type comparisons clarification #66199
Comments
https://docs.python.org/3.5/library/stdtypes.html Despite the location, this seems to strong a statement, because of subclasses and classes which define __eq__. A first attempt at rewording: Existing: """ Non-identical instances of a class normally compare as non-equal unless the class defines the __eq__() method. Instances of a class cannot be ordered with respect to other instances of the same class, or other types of object, unless the class defines enough of the methods __lt__(), __le__(), __gt__(), and __ge__() (in general, __lt__() and __eq__() are sufficient, if you want the conventional meanings of the comparison operators). The behavior of the is and is not operators cannot be customized; also they can be applied to any two objects and never raise an exception. Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below). --> """ Other comparisons refer to an object's meaning, and therefore must be defined by the object's own class. "abc" == "abc" is always True, because the str class defines equality that way. The default implementation uses is (object identity) for equality and raises a TypeError for the ordering comparisons. Defining the __eq__ method allows different instances to be equivalent; also defining the __lt__ method allows them to be ordered in the normal way. Some classes will also define __le__, __ne__, __ge__, and __gt__, either for efficiency or to provide unusual behavior. Except for numbers, instances of two different standard classes will be unequal, and will raise a TypeError when compared for ordering. Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below). |
'type' and 'class' are two different names for the same concept in python3, so this paragraph simply appears to be out of date and indeed in need of complete rewording. |
I think the patch for bpo-12067 covers all of the suggested points here, and is more accurate in some cases. |
Actually, this is about a different section of the documentation. But it might still be best to update /Doc/reference/expressions.rst first in bpo-12067, and then sort out /Doc/library/stdtypes.rst to match. Why do we need a dedicated section in Built-in Types about Comparisons? I think it might make more sense to just document how comparisons work separately for each type (Numeric, Sequence, Text, etc), if this is not already done. |
It is nice to have some of that information collected together. I think people learn about comparison logic as a single topic rather than piecemeal type by type. To Jim's point, the discussion of "is" and "is not" should probably be factored-out (their meaning is type-invariant and is not overridable with a dunder method). Also, they don't have the same reflective logic as the rich comparisons. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: