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 ste...@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-le...@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`. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/DIZPDIRF3254ZZZMCWSPEUOBLKC2MQZZ/ Code of Conduct: http://python.org/psf/codeofconduct/
