Performance of int/long in Python 3

[Dave Angel]

On 04/03/2013 12:30 PM, Ian Kelly wrote:
> On Wed, Apr 3, 2013 at 5:52 AM, Dave Angel <davea at davea.name> wrote:
>> I'm also puzzled.  I thought that the sort algorithm used a hash of all the
>> items to be sorted, and only reverted to a raw comparison of the original
>> values when the hash collided.  Is that not the case?  Or is the code you
>> post here only used when the hash collides?
>
> I think you are mistaken, because I don't see how that could work.  If
> the hashes of two items are different then you can assume they are not
> equal, but sorting requires a partial ordering comparison, not simply
> an equality comparison.  You cannot determine which item is less or
> greater than the other from the hash values alone.
>

You are of course correct.  The particular data that Neil had provided 
might well have had many duplicates, but that won't be the typical case, 
so there's not much point in doing an unordered hash.  I guess I was 
confusing it with the key= argument for modifying sort order, where the 
key function might replace a slow-to-compare data type with something 
faster.

-- 
DaveA