<div dir="auto">And if this is a method on a custom *collection*, it can do whatever it wants in MyCollection.sort() already.</div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 3, 2017 7:14 PM, "David Mertz" <<a href="mailto:mertz@gnosis.cx">mertz@gnosis.cx</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">I'm not sure I understand the motivation to make elements *sortable* but not comparable. If an arbitrary order is still useful, I'd think you'd want to be able to tell how two particular elements *would* sort by asking a<b.</div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 3, 2017 6:55 PM, "Bruce Leban" <<a href="mailto:bruce@leban.us" target="_blank">bruce@leban.us</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="m_-8802661548947726493m_-8972381640637488283gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br class="m_-8802661548947726493m_-8972381640637488283gmail-Apple-interchange-newline">On Sun, Dec 3, 2017 at 3:06 PM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span><wbr> wrote:<br></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><div>However, if you are writing a custom class ... <snip></div><br class="m_-8802661548947726493m_-8972381640637488283gmail-Apple-interchange-newline"><div>But what if there was a sort key magic method: <br><br> <span style="font-family:monospace,monospace">__key__</span> or <span style="font-family:monospace,monospace">__sort_key__ </span>(or whatever)<br></div><div><br></div><div>that would be called by the sorting functions <snip></div><div><br></div><div>It seems this would provide a easy way to make custom classes sortable that would be nicer for end users (not writing key functions), and possibly more performant in the "usual" case.<br></div></div></div></blockquote><div><br></div></div><div class="gmail_quote">On Sun, Dec 3, 2017 at 4:57 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-8802661548947726493m_-8972381640637488283gmail-"><br>
</span>This shows the problem with putting the key function into the data type.<br>
What if I want to sort AttrDicts by their list of keys instead? Or their<br>
(key, value) pairs? What is so special about sorting by ID (which may<br>
not even exist!) that it deserves to be part of the AttrDict itself?</blockquote><div><div><br></div><div>I think you're arguing against this for the wrong reason. Chris was talking about custom classes having the <i>option</i> of making them sortable by providing a key method in the class definition. This strikes me as useful and I can imagine having used this if it were available. What you're saying is that there are classes which probably shouldn't define a __sort_key__ function, which I quite agree with. But I don't think it's a good argument against this proposal.</div><div><br></div><br class="m_-8802661548947726493m_-8972381640637488283gmail-Apple-interchange-newline">On Sun, Dec 3, 2017 at 3:06 PM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span><wbr> wrote: <br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Am I imagining the performance benefits?</div></div></div></blockquote><div><br></div><div>Maybe. Looking strictly at O(-) cost, there's no difference between a key function and comparison operators. Sure it might potentially only make O(n) calls to the key function and O(n log n) calls to compare the keys vs. O(n log n) calls to the comparator functions but that might not actually be faster. There certainly are cases where implementing a key function would be quite slow.</div><div> </div></div></div></div><div class="gmail_extra">--- Bruce</div></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofco<wbr>nduct/</a><br>
<br></blockquote></div></div>
</blockquote></div></div>