> We could do that and not incur performance issues.  However, it would expand the API and double the size of the code.  

If the preference is to not support this use-case, then I'd rather the decorator simply raise an exception and tell me this is going to be a problem so I can eagerly implement the workaround.

> It seems like a rare niche use case, and the workaround is simple.

It does seem like there are various times that one might want to make classes orderable, for example if they are bound to IDL objects or database tables; the use-case where I ran into this was something like that.

> For production code, I usually recommend writing out the other three methods (that is less magical, runs faster, easier to test, has fewer  dependencies, and makes the tracebacks more readable.

Wait, is the suggestion here that @total_ordering is not suitable for production?