Raymond Hettinger <rhettin...@users.sourceforge.net> added the comment:
In that case, I think it best to leave nsmallest/nlargest as-is. By appending ties to the result, it becomes harder to implement policy decisions on what to do with those ties (perhaps listing them separately or splitting their prizes n-ways). A preferred approach is to use existing tools such as: last=result[1]; [last]*s.count(last). Alternatively, result=sorted(s) works well with bisect to find the cut points. Also, my instincts say that it is weird ask for n-items and get a result with potentially more than n. Looking at the source code for nsmallest/nlargest, I think this build-out would complicate the code quite a bit, so the use cases would need to be more compelling. The way the nsmallest/nlargest work is that they maintain an n-length buffer and loop over the entire input while remembering only the best-n-so-far. That approach doesn't easily extend to tracking best-n-so-far-and-all-ties. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5669> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com