Guido van Rossum wrote:
On Tue, Mar 3, 2020 at 10:43 AM Steve Jorgensen firstname.lastname@example.org wrote:
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. Right. That's a much better term. Orderable and ProtoOrderable. Or even PartialOrderable and Orderable. This would follow Rust's
PartialOrd and Ord (https://doc.rust-lang.org/std/cmp/trait.PartialOrd.html and https://doc.rust-lang.org/std/cmp/trait.Ord.html). But beware, IIRC there are pathological cases involving floats, (long) ints and rounding where transitivity may be violated in Python (though I believe only Tim Peters can produce an example :-). I'm honestly not sure that that's enough to sink the idea. (If it were, NaN would be a bigger problem.)
Yeah. Violations of transitivity are already breaking their contracts, so having a new way of expressing the contract has no affect on that.
The problem I came up with trying to spike out my proposal last night is that there doesn't seem to be anyway to implement it without creating infinite recursion in the `issublcass` call. If I make `Orderable` a real or virtual subclass of `ProtoOrderable` and `Orderable`'s `__subclasshook__` or metaclass `__subclasscheck__` (I tried both ways) tries to check whether `C` is a subclass of `ProtoOrderable`, then an infinite recursion occurs.
It wasn't immediately obvious to me why that is the case, but when I thought about it deeply, I can see why that must happen.
An alternative that I thought about previously but seems very smelly to me for several reasons is to have both `Orderable` and `NonOrderable` ABCs. In that case, what should be done to prevent a class from being both orderable and non-orderable or figure out which should take precedence in that case?
As a meta-solution (wild-assed idea) what if metaclass registration could accept keyword arguments, similar to passing keyword arguments to a class definition? That way, a single ABC (`ProtoOrderable` or whatever better name) could be a real or virtual subclass that is explicitly orderable or non-orderable depending on `orderable=<True/False>`.