Hacker News Reader

Python is almost as bad as C++ when it comes to making custom classes sortable. In Python 2 there was had __cmp__, which was roughly the same as C++'s new spaceship operator, but Python 3 inexplicably removed it in favor of only having individual comparison operators like __eq__, __lt__, __gt__, etc. Oh, and functools.total_ordering, which lets you "only" define __lt__ and __eq__ and get the rest automatically implemented, but that's still two things to define when __cmp__ was only one.

IIRC the reason is that people would regularly screw up __cmp__ (despite the cmp built-in being available), it’s harder to fuck up simple boolean results that the any-integer-coerced-to-3-state of cmp.

Python 3 also removed the “everything is comparable” misfeature of P2, providing way lower incentive to implement ordering: if your type is not orderable, a user knows to go with key functions.

I don't trust someone who can't implement `__cmp__` to implement `__lt__` either.

Experience says you're way wrong, simply because combining a sequence of sub-lt calls is way simpler and shorter than combining a sequence of cmp:

    def __lt__(self, other):
        return self.a < other.a and self.b < other.b and self.c < other.c

meanwhile

    def __cmp__(self, other):
        v = cmp(self.a, other.a)
        if v != 0:
            return v
        v = cmp(self.b, other.b)
        if v != 0:
            return v
        v = cmp(self.c, other.c)
        if v != 0:
            return v
        return 0

Rust (for instance) makes the latter less offensive (and error-prone) by providing built-in combinators: https://doc.rust-lang.org/std/cmp/enum.Ordering.html

    impl Ord for Thing {
        fn cmp(&self, other: &Self) -> Ordering {
            self.a.cmp(&self.a)
                .then(self.b.cmp(&other.b))
                .then(self.c.cmp(&other.c))
        }
    }

But that first comparison function is usually not what you want, you want lexicographic ordering. This very example is in fact discussed in the article, as an example to how people often mess this up...

> But that first comparison function is usually not what you want

All those functions implement the same comparison, the first is simply not including the similarly trivial implementation for eq:

    def __eq__(self, other):
        return self.a == other.a and self.b == other.b and self.c == other.c

> you want lexicographic ordering

Every word here makes sense but the objection makes none. What are you trying to say exactly?

The issue is that __cmp__ wasn't "only one". For one thing, you generally want equality independent of ordering, so defining an explicit __eq__ that just handles equality is a decent idea. Otherwise either you define both cmp and eq, or you have your cmp including stuff like isinstance checks, in some cases, and having to decide if your custom class is more, or less, than a string (as masklinn notes below). Note: there's literally only bad answers here. Does cmp raise an exception? Yikes. Is MyCustomObject less than "hello world", or more, or does it depend on the internal state of MyCustomObject? Yikes, why do I have to choose? MyCustomObject isn't like "hello world".

So you want eq, seperate from cmp. Then you still need a way to define ordering, so either write them all for weird cases, or just pick one and have total_ordering do the legwork.

So why not just define `__eq__` and `__cmp__`. It just seems to make so much more sense... and only `__eq__` only if you need it different from `__cmp__ == 0`.

Removing `__cmp__` was a step backwards IMHO.

Because requiring you to define eq is more correct. Equality and ordering are different concepts. If they wanted to keep cmp, the only correct choice would be to require eq if you define cmp.

This again goes back to what masklinn said: a total ordering across all objects in python is a misfeature. The idea that `object() < 13 < "hello world" < 3+2j < [(frozenset(), frozenset())] < {type: int}` should evaluate to anything but a TypeError is horrifying!

And once you make that decision, if an object implements cmp, it must implement eq (because the safe thing should be the default, and allowing people to implement cmp in isolation lets them shoot themselves in the foot). And at that point, cmp is more work to write than le or gt, so instead just implement eq, and then if you want it, le or gt + total_ordering, or if you need weird things implement each method individually.

In practice, I've also found it much easier to reason about eq or le than cmp. People like to be tricky with cmp, and even when they don't, returning -1 or 1 is less explicit than just returning True or False.

> The idea that `object() < 13 < "hello world" < 3+2j < [(frozenset(), frozenset())] < {type: int}` should evaluate to anything but a TypeError is horrifying!

At least it evaluates to False.

Which means, that if you flip some of those operators, it will be True... Won't make sense though.

So Python has reverted to the pre-C++20 state but without the ability to redefine other operators? Can you even make a proper custom float type in Python then?

You can define all the operators explicitly if you wish. However, the common case is made easier, define only __eq__ and one of the others (__gt__ or __le__ usually) and @functools.total_ordering will derive all of the others for you.

Okay, it's exactly the pre-C++20 state. That's actually funny.

I don't think that's true, python had no concept of strong vs. weak equality and ordering. cmp returned either -1, 0, or 1 (or at least, it was treated that way). There was no way to describe "unequal, but not orderable".

That's the flaw which cpp avoids, although it remains to be seen if implementing complex spaceships is worth it.

Or I guess, python is now in the pre-cpp20 state, but was never in the post-cpp20 state, so it didn't revert. Python's cmp was broken.

What's not true?

I didn't say that Python was in post-cpp20. Maybe you wanted to comment on my previous comment.

To rewind a bit, you stated "So Python has reverted to the pre-C++20 state..."

Which is the statement I originally took issue with.

> C++ compiler needs to provide robust compile-time and run-time checks to tell programmers that things are wrong

Hard to do without breaking backward compatibility, which is among the main reasons why we still write C++.

It’s done in C#. CS0216 forces you to implement operators in sets, e.g. can’t implement `==` without also implementing `!=` it won’t build otherwise: https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0216

And these warnings are printed for compatibility with containers: https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0660 https://docs.microsoft.com/en-us/dotnet/csharp/misc/cs0661

> CS0216 forces you to implement operators in sets, e.g. can’t implement `==` without also implementing `!=` it won’t build otherwise

So… that you can provide incoherent implementations of == and != instead of the system just generating one based on the other?

They don’t have to return bool.

Even when they return bool, in some cases both greater and less must return false. Example: https://en.wikipedia.org/wiki/NaN#Comparison_with_NaN

I'm not saying you shouldn't be able to implement both such that they're not coherent, I'm saying requiring implementing both when the system could provide one based on the other (as e.g. Haskell, Rust or Python do) is an unforced error and a pointless footgun.

> unforced error and a pointless footgun

I think it’s the other way. Providing one based on the other is a pointless footgun.

The experience doesn’t end when you’ve made machine code from your source. Developers debug stuff. Developers support their products, sometimes analyzing crash dumps. The more magic is used in the compiler, the harder it is to debug and support software.

Sometimes that’s justified, e.g. in C# there’s substantial amount of compiler magic for generators and async functions. But these 2 features save substantial amount of code complexity.

Implementing != from == and > from < only provides minimal profit. The manual implementation is a single line method.

Another reason, C# is different language than Rust or Python. It has awesome support for OOP and runtime reflection. What should happen if you use reflection to get op_Inequality for a class where only == is defined? What should happen if you define == in a base class and != in a derived one?

>> C++ compiler needs to provide robust compile-time and run-time checks to tell programmers that things are wrong

> Hard to do without breaking backward compatibility, which is among the main reasons why we still write C++.

Although the language specification may need to preserve backwards compatibility, compilers can offer strictness warnings that go beyond that (e.g. -Wstrict). And the standards have deprecated and removed things as well. It’s not a straightjacket.

For the last 20 years, C++ standard library uses `operator <` for std::sort, and for building red black trees like std::map and std::set; `operator >` is not used.

Making this a warning would probably break too much existing code.

Well, you can use whatever extremities of strictness and year of standard for new code (mine is currently c++17 + pretty much every possible warning). And you can keep lower levels of warning for older, or third party code.

In the case of the standard library, the whole library is being hoisted to use <=> in c++ 20. Old code will still work with the latest library of course.

> And you can keep lower levels of warning for older, or third party code.

Maybe, but I think it’s hard to do in practice. Many C++ libraries are header only because templates, i.e. old and new stuff is mixed really well.

Differentiating warnings is possible with #pragma but they aren’t portable across compilers.

What we do is make a small shim to a more modern interface and then compile the shim, with the includes, in c++11 mode with whatever warnings disabled as necessary.

I know this doesn't work for everyone and we can't even do it with everything. But it helps a lot.

> The C++ compiler needs to provide robust compile-time and run-time checks to tell programmers that things are wrong, like: “your operator does not meet the requirements of the sort algorithm”.

MSVC does that in debug mode - it will assert if you use an invalid comparator for e.g. map / set. No reason it couldn't be further improved, or a clang-tidy check written for that.

MSVC also does interator validation and bounds checking in debug mode, alongside its macro based contracts.

Some things are actually more productive in MS land for security conscious coding. A nice side effect from all those Windows 9X exploits.

It has saved my behind a handful of times. Also shoutout to unordered_map for the debug build runtime check that equal keys have equal hashes.

(just by pure curiosity, are you Vesa Norilo ? if so, great work on Kronos !)

That's me! Thank you, much appreciated.

I do not think it is trivial to prove at compile time that an a comparison operator is correct: I think you need a fancy type system for that. Asserting correctness at runtime is of course possible, but it has non trivial cost. Most std libraries provide a debug mode that will catch these sort of issues.

To enforce correctness, you'd need to demand proofs. I think the most common approach for this is dependent types. I think you'll have to wait another 20 years before they become mainstream.

I'm working on a game. I have a templated 2D vector implementation. Tile positions use Vector2<int>, entity positions and such use Vector2<float>.

I wanted a map from tile position to something else. I found that I had to implement operator<, because std::map uses operator<. That's an issue, because:

1. I didn't want to implement every single possible comparison operator just to put vectors in an array, but also didn't want to arbitrarily make `foo < bar` legal but `foo > bar` illegal.

2. What does it even mean for one vector to be "bigger than" another vector? For vector math purposes, I'd maybe expect operator< to compare magnitudes, but that would be absolutely terrible for std::map. Not everything has an unambiguous concept of "smaller than".

In the end I just made a std::map<std::pair<int, int>> and added an implicit conversion from Vector2<T> to std::pair<T, T>.

Oh, that is simple: in associative containers, you can pass an external comparator as additional template parameter. Use that. Don't implicitly convert, it will bite you.

Oh thanks, I somehow didn't see that. That does sound better yeah.

And also see if you're better off with an std::unordered_map or a custom sorted-array implementation of a map.

In addition to the sibling’s comment on explicitly passing inna comparator, note that std::map is an ordered dictionary and requires an ordering on your elements. It sounds like you may have preferred hash_map

I don't know, the way std::pair works is that it compares the two elements' `first`, or their `second` if `first` happens to be equal. That seems pretty good; lookup should still be O(n).

I'll keep hash_map in mind though, and maybe do some performance testing to see which is actually faster.

std::map is incredibly slow (and allocates willy-nilly), see https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-01-o... for a comparison of modern hash maps. Or at least boost::flat_map if you need ordering but don't do many insertions / removals and care instead for fast iteration on the map.

Note: when I say "incredibly slow", it is relative to what is possible to achieve in C++ - it will still roll over many other languages's map implementations.

Chromium advised for their typical use cases to use std::map in favor of std::unordered_map. And they also provide own version of flat_map.

[1] - https://chromium.googlesource.com/chromium/src/+/master/base...

In some cases, the performance of std::unordered_map is fixable with a custom allocator: https://github.com/Const-me/CollectionMicrobench