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

Reply via email to