Pourquoi un floating point clé de dictionnaire remplacer une clé entière avec la même valeur?

Tout d'abord: le comportement est documenté de manière explicite dans la documentation pour l' de hachage fonction:

hash(object)

Retour à la valeur de hachage de l'objet (si il en a un). Les valeurs de hachage sont
les nombres entiers. Ils sont utilisés pour comparer rapidement les clés de dictionnaire au cours d'une
recherche dans le dictionnaire. Des valeurs numériques qui permettent de comparer l'égalité ont la même
la valeur de hachage (même si elles sont de différents types, comme c'est le cas pour 1
et 1.0).

Deuxièmement, une limitation de hachage est indiqué dans la documentation pour objet.__hash__

object.__hash__(self)

Appelée par la fonction intégrée dans hash() et pour les opérations sur les membres de
haché collections, notamment les set, frozenset, et dict. __hash__()
doit retourner un entier. La seule propriété est que les objets
pour comparer l'égalité ont la même valeur de hachage;

Ce n'est pas spécifique à python. Java a la même mise en garde: si vous mettez en œuvre hashCode ensuite, pour que les choses fonctionnent correctement, vous doit le mettre en œuvre de manière à ce que: x.equals(y) implique x.hashCode() == y.hashCode().

Donc, python a décidé que 1.0 == 1 détient, par conséquent, il est forcé pour fournir une implémentation pour hash tels que hash(1.0) == hash(1). L'effet secondaire est que 1.0 et 1 agissent exactement de la même manière que dict clés, d'où le comportement.

En d'autres termes, le comportement en lui-même ne doit pas être utilisé ou utile en quelque sorte. Il est nécessaire. Sans ce comportement, il y aurait des cas où vous pourriez accidentellement écraser une clé différente.

Si nous avions 1.0 == 1 mais hash(1.0) != hash(1), on pourrait encore avoir un collision. Et si 1.0 et 1 entrent en collision, la dict utilisera l'égalité pour être sûr qu'ils sont de la même clé ou pas et kaboom la valeur est écrasée, même si vous en aviez l'intention d'être différent.

La seule façon de l'éviter serait d'avoir 1.0 != 1, de sorte que le dict est capable de distinguer entre eux, même en cas de collision. Mais il a été jugé plus important d'avoir 1.0 == 1 que pour éviter le comportement que vous voyez, depuis que vous avez pratiquement jamais utiliser floats et ints comme les clés de dictionnaire, de toute façon.

Depuis python essaie de cacher la distinction entre les nombres en convertissant automatiquement lorsque nécessaire (par exemple,1/2 -> 0.5) il est logique que ce comportement se reflète même dans de telles circonstances. C'est plus cohérent avec le reste de python.

---

Ce comportement apparaît dans tout mise en œuvre lorsque la mise en correspondance des touches est au moins en partie (comme dans un tableau associatif) fondée sur des comparaisons.

Par exemple, si un dict a été mis en œuvre à l'aide d'un rouge-noir arbre ou un autre type d'équilibre du BST, lorsque la clé 1.0 est regardé les comparaisons avec d'autres touches, serait de retour les mêmes résultats que pour 1 et afin qu'ils continuent à agir de la même manière.

De hachage cartes nécessitent un soin encore plus grand en raison du fait que c'est la valeur de hachage est utilisé pour trouver l'entrée de la clé et des comparaisons sont faites seulement par la suite. Afin de briser la règle présentée ci-dessus signifie que vous voudrais vous présenter un bug qui est assez difficile à repérer car à la fois la dict semblent fonctionner comme vous le souhaitez, et à d'autres moments, lorsque les changements de taille, elle commence à se comporter de manière incorrecte.

---

Noter qu'il n'y serait être un moyen de résoudre ce problème: avoir un hachage à la carte/BST pour chaque type inséré dans le dictionnaire. De cette façon, il ne pouvait pas être tout les collisions entre les objets de type différent et comment == compare ne serait pas question lorsque les arguments de différents types.

Toutefois, cela ne ferait que compliquer la mise en œuvre, il serait probablement inefficace depuis hachage cartes ont à garder tout à fait à quelques endroits afin d'avoir O(1) les temps d'accès. Si ils sont trop pleins les performances diminuent. Le fait d'avoir plusieurs cartes de hachage moyen de gaspiller plus d'espace et aussi, vous devez d'abord choisir les hash map à regarder avant même de commencer la réelle recherche de la clé.

Si vous avez utilisé techniciennes se chargent de vous aimerais tout d'abord avoir à rechercher le type et le effectuer un second de recherche. Donc, si vous allez à l'utilisation de nombreux types de vous finirais avec deux fois plus de travail (et de la recherche permettrait de prendre en O(log n) au lieu de O(1)).

Dictionnaires sont mis en œuvre avec une table de hachage. Chercher quelque chose dans une table de hachage, vous commencez à la position indiquée par la valeur de hachage, puis de rechercher les différents lieux jusqu'à ce que vous trouver une clé de valeur égale ou un seau vide.

Si vous avez deux valeurs clés qui permettent de comparer l'égalité des différentes tables de hachage, vous pouvez obtenir des résultats contradictoires en fonction de la valeur de la clé était dans la perquisitionnés ou pas. Par exemple ce serait plus probable que la table est pleine. C'est quelque chose que vous voulez éviter. Il semble que les développeurs Python avait cela à l'esprit, depuis le haut- hash fonction renvoie la même valeur de hachage pour l'équivalent de valeurs numériques, peu importe si ces valeurs sont int ou float. Notez que cela s'étend à d'autres types numériques, False est égal à 0 et True est égal à 1. Même fractions.Fraction et decimal.Decimal respecter cette propriété.

L'exigence que si a == b puis hash(a) == hash(b) est documenté dans la définition de objet.__hash__():

Appelée par la fonction intégrée dans hash() et pour les opérations sur les membres de haché collections, notamment les set, frozenset, et dict. __hash__() doit retourner un entier. La seule propriété est que les objets qui permettent de comparer l'égalité ont la même valeur de hachage, il est conseillé de faire en quelque sorte mélanger (par exemple à l'aide de ou exclusif) les valeurs de hachage pour les composants de l'objet qui jouent également un rôle dans la comparaison d'objets.

TL;DR: un dictionnaire serait briser si les touches qui ont comparé l'égalité n'a pas de carte de la même valeur.

Je suis d'accord avec d'autres, qu'il est logique de traiter 1 et 1.0 que même dans ce contexte. Même si Python n'a le traiter différemment des autres, il serait probablement une mauvaise idée d'essayer d'utiliser 1 et 1.0 comme les clés distinctes pour un dictionnaire. Sur l'autre main -- j'ai du mal à penser à un cas d'utilisation pour l'utilisation de 1.0 comme un alias pour 1 dans le contexte de touches. Le problème est que la clé est littérale ou il est calculé. Si c'est un littéral de la clé alors pourquoi ne pas simplement utiliser 1 plutôt que 1.0? Si c'est une clé calculée -- arrondi erreur pourrait muck les choses:

>>> d = {}
>>> d[1] = 5
>>> d[1.0]
5
>>> x = sum(0.01 for i in range(100)) #conceptually this is 1.0
>>> d[x]
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    d[x]
KeyError: 1.0000000000000007

Donc, je dirais que, de façon générale, la réponse à votre question "est-ce toujours utile pour le langage?" "Non, probablement pas."