>
> Taking one step back out of the realm of mathematical definition, however,
> the original idea was simply to distinguish what I now understand to be
> "totally ordered" types from other types, be they "partially ordered" or
> unordered — not even having a full complement of rich comparison operators
> or having all but using them in weirder ways than sets do.
>

It sounds like you want a mechanism to blacklist certain types (such as
sets) from being considered totally ordered while assuming that everything
else with the right operators is totally ordered.

ABCs and classes in general are usually whitelists that inform the user
that the implementation satisfies certain properties. They're explicit
rather than implicit.

If you want to validate arguments, you're being conservative and safe. It's
safer to require that an argument is on a whitelist - if the user forgets
the whitelist, the validation will fail, the user will be reminded, and
they can fix it. For example they can register their class as a virtual
subclass. If the user forgets to put their type on a blacklist, then the
argument validation can't do its job.

I suggest having ABCs PartiallyOrdered and TotallyOrdered, where:

- TotallyOrdered is a subclass of PartiallyOrdered, as is the case
mathematically.
- Most familiar types with the operators are TotallyOrdered.
- Sets are merely PartiallyOrdered.
- sorted, min and max will require Iterable[TotallyOrdered].
- @functools.total_ordering automatically registers the class as
TotallyOrdered.

Some use cases probably exist that require PartiallyOrdered but
where TotallyOrdered is optional and irrelevant.

Users that want to take a generous blacklist approach can check that
`<operators are present> and not (isinstance(x, PartiallyOrdered) and not
isinstance(x, TotallyOrdered))` or equivalently `<operators are present>
and (not isinstance(x, PartiallyOrdered) or isinstance(x, TotallyOrdered))`
which would exclude sets and any other case where the person who defined
the class thought about this stuff.
_______________________________________________
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/74UTARRTP5TZSITJJIZUUKV6FMDHXM2A/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to