Message302905
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). |
|
Date |
User |
Action |
Args |
2017-09-25 02:15:27 | rhettinger | set | recipients:
+ rhettinger, ncoghlan, Mikołaj Babiak |
2017-09-25 02:15:27 | rhettinger | set | messageid: <1506305727.68.0.85475570763.issue31145@psf.upfronthosting.co.za> |
2017-09-25 02:15:27 | rhettinger | link | issue31145 messages |
2017-09-25 02:15:27 | rhettinger | create | |
|