A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2003-October/038768.html below:

[Python-Dev] decorate-sort-undecorate

[Python-Dev] decorate-sort-undecorate [Python-Dev] decorate-sort-undecorateAahz aahz at pythoncraft.com
Wed Oct 15 15:26:10 EDT 2003
On Wed, Oct 15, 2003, Guido van Rossum wrote:
> 
> That sounds like an extremely roundabout way of doing it; *if* there
> had to be a way to request a stable sort, I'd say that specifying a
> 'stable' keyword would be the way to do it.  But I think that's
> unnecessary.
> 
> Given that the Jython folks had Tim's sort algorithm translated into
> Java in half a day, I don't see why we can't require all
> implementations to have a stable sort.  It's not like you can gain
> significant speed over Timsort.

But in the discussion leading up to adopting Timsort, you (or Tim, same
difference ;-) explicitly said that you didn't want to make any doc
guarantees about stability in case the sort algorithm changed in the
future.  I don't have an opinion about whether we should keep our
options open, but I do think there should be a clearly explicit decision
rather than suddenly assuming that we're going to require Python's core
sort to be stable.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4