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: l...@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.pyt...@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
--
https://mail.python.org/mailman/listinfo/python-list
