homepage

We already have recommendations in the heapq documentation on how to do a work-around. I'm looking at the more general problem of how can we make it easy once again to decorate a value with a sort value (not just for heaps but for anyplace where comparisons are made).
I would like our preferred answer to be something better than, "take all your existing functions that use comparisons and make new variants that compute and cache key functions". Instead, I would rather, "keep your existing functions simple and just wrap your data in something that specifies comparison values that are computed just once". 
The old Schwartzian transform (decorate-compare-undecorate) had broad applicability but was effectively killed when a simple tuple no longer served for decoration. 
FWIW, the DataClass discussion has also ventured into this territory (the field definitions can specify whether or not a field is included in the rich comparison methods).