Merci pour tes commentaires.
J’ai de mon côté commencé une relecture et commencé à corriger quelques fautes et mauvaises formulations.
Tu expliques très bien comment utiliser les conteneurs mais pas quand le faire. J’ignore si c’est possible, mais il me semble intéressant de fournir un cas d’utilisation typique pour chaque.
En fait, j’hésitais déjà à présenter le module, me demandant s’il était vraiment à sa place dans le cours, ce dernier ayant surtout vocation à montrer comment implémenter ses structures que documenter l’existant.
Je vais voir ce que je peux faire, mais je n’ai pas envie d’alourdir trop cette section, alors qu’elle n’est à la base qu’une annexe du chapitre Conteneurs.
Un mot sur comment ça se traduit en mémoire ?
Je pourrais essayer d’en toucher un mot, oui. Mais c’est souvent délicat de parler de Python et de la mémoire.
J’ai toujours eu du mal avec ça. Si
Noneest un singleton, l’égalité est équivalente à l’identité, non ? Qu’apporte donc l’utilisation deispar rapport à==?
Ce que je vais dire là est à prendre avec des pincettes, je ne suis pas allé voir dans les sources ce qu’il en était réellement.
Je dirais que c’est surtout qu’il est inutile d’utiliser == alors que is fait le travail, plus simplement.
is n’a qu’à comparer les adresses des deux objets là où == doit localiser la méthode __eq__ puis l’appeler, et c’est celle-ci qui utilisera is en dernier lieu.
Le résultat serait le même, mais ça évite des appels inutiles.
Et je ne sais pas s’il n’y a pas quelque part des objets qui seraient égaux à None, sans être None.
Un mot sur la théorique irréversibilité d’une fonction de hashage ? Le lecteur pourrait se poser la question pour compresser ses données.
Je ne trouvais pas ça forcément pertinent, mais je peux ajouter un commentaire dessus.
Le terme "collision" n’est-il pas plus répandu ?
Si, je corrigerai.
Tu pourrais indiquer quelle est la fonction de hashage par défaut.
Elle me semble tout de même assez complexe. Elle fait intervenir de l’aléatoire et réserve un sort particulier pour les nombres.
Je ne comprends pas le "mais". Plutôt "et devrait" ?
[…]
Edit : en fait tu en parles plus bas. Peut-être serait-il judicieux d’inverser les parties "À quoi servent-ils ?" et "Implémentation", pour que le lecteur ait sa réponse plus rapidement.
Peut-être, je voulais attendre d’avoir expliqué l’utilité avant d’en venir à l’implémentation. Je regarderai quelle tête ça peut avoir en inversant les sections. Ou alors juste remonter la remarque sur les mutables ?
Comment Python distingue-t-il les deux situations suivantes ? Arrive-t-il à détecter la surchage de
__eq__? Comment sait-il si mon implémentation de cette méthode dépend de l’état de l’objet ?
L’implémentation d’__eq__ dans une classe fait automatiquement disparaître le __hash__ par défaut (enfin, c’est plutôt que le __hash__ par défaut n’est pas ajouté si __eq__ est redéfinie).
Dans cette partie, tu ne parles que des dictionnaires, mais j’imagine qu’il y a d’autres applications. A défaut de toutes les mentionner, il me semble judicieux d’en présenter au moins une autre classique ou, au minimum, d’en citer l’existence (i.e. d’indiquer que les hashes ne servent pas qu’aux dictionnaires).
C’est assez difficile de trouver une autre utilisation de hash en Python que pour les ensembles et les dictionnaires (qui reflètent les deux la même utilisation).
Mais ça peut bien sûr optimiser le calcul de l’égalité entre deux objets, si le hash est stocké en cache (puisque invariable) : si les hashs sont différents, on sait déjà que les objets sont différents.