Guido van Rossum wrote:
I think it’s usually called Orderable. It’s a useful concept in static type checking too (e.g. mypy), where we’d use it as an upper bound for type variables, if we had it. I guess to exclude sets you’d have to introduce TotalOrderable. On Tue, Mar 3, 2020 at 04:03 Steve Jorgensen stevej@stevej.name wrote:
I have encountered cases in which I would like to validate that an argument can be properly compared with other instances of its type. This is true of numbers, strings, dates, … but not for NoneClass, type, …. One way that I have tried to handle this is to check whether the object can be compared to itself using >, <, >=, and <= and that it is neither > or < itself and is both >= and <= itself. The most glaring example of why this is insufficient is the set type. A set object meets all of those criteria, but given any 2 instances, it is not true that if set a > b is False then a <= b is True. The operators are not acting as comparisons of relative magnitude in this case but as tests for superset/subset relations — which is fine and good but doesn't help with this situation. What I think would be helpful is to have a Magnitude abstract base class that is a subclass of ProtoMagnitude (or whatever better names anyone can imagine). The subclass hook for Magnitude would return True for any class with instance methods for all of the rich comparison methods, but it would skip that check and return False for any real or virtual subclass of ProtoMagnitude (overridable by registering as a Magnitude subclass). The, set type would then be registered as a virtual base class of ProtoMagnitude but not Magnitude so that issubclass(set, Magnitude) would return False. For performance optimization, the module that defines these ABCs would register the obviously appropriate built-in and standard-lib types with Magnitude: Number, str, list, tuple, date, … Why not have this be a separate distribution package? This concept is only reliable if all of the code that makes use of it shares a common implementation. It does no good to register a class as ProtoMagnitude, for instance, if an instance of that will passed to code in another library that is unaware of the ProtoMagnitude and Magnitude ABCs in the package, or maybe has its own independent system for attempting to accomplish the same goal.
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7WC4SF... Code of Conduct: http://python.org/psf/codeofconduct/ -- --Guido (mobile)
Right. That's a much better term. `Orderable` and `ProtoOrderable`.