Raymond Hettinger added the comment: 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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31145> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
