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/7WC4SF2GYVLP56K6Q74OKFPJGHGWAPIP/
Code of Conduct: http://python.org/psf/codeofconduct/