Why no list as dict key?

[Lars Liedtke]

May I stupidly ask, why one would want to use an iterable (even 
immutable) as dict key?

I thought keys were meant to be something "singular". And yes you could 
also combine a string to be a key, and if you combine a string it would 
be somehow the same as a tuple. But anyways I still fail to see the 
application for that, which is most propably to ignorance rather than 
criticism.

Cheers

Lars


-- 
Lars Liedtke
Software Entwickler

			
Phone: 	
Fax: 	+49 721 98993-
E-mail:	lal at solute.de


solute GmbH
Zeppelinstraße 15				
76185 Karlsruhe
Germany


Marken der solute GmbH | brands of solute GmbH
billiger.de | Shopping.de 


Geschäftsführer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten
Webseite | www.solute.de
Sitz | Registered Office: Karlsruhe
Registergericht | Register Court: Amtsgericht Mannheim
Registernummer | Register No.: HRB 110579
USt-ID | VAT ID: DE234663798


Informationen zum Datenschutz | Information about privacy policy
http://solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php

Am 21.04.22 um 07:00 schrieb Chris Angelico:
> On Thu, 21 Apr 2022 at 13:23, Abdur-Rahmaan Janhangeer
> <arj.python at gmail.com> wrote:
>> Assumes checking for object equality before inserting.
>> If they are they same, do we need different hashes?
>>
> The point of the hash is to find things that are equal. That's why
> 1234, 1234.0, and 0j+1234.0 all have the same hash.
>
> If equality changes, the hash does too. It's certainly possible to
> have the hash come from object identity, but then so must equality. If
> you want that, it's easy to do - just create your own object for the
> state, rather than using a list. But then you have to use the original
> object to look things up, instead of matching by the data.
>
> Hashes are simply a short-hand for equality. That's all.
>
> ChrisA