En tant que titre. Je veux dire, vous pouvez invoquer next(obj) et pointe vers l'élément suivant. L'état interne de l'itérable ou du générateur va donc changer.
Pourquoi sont-ils hachables ?
Réponses
Trop de publicités?
La règle générale pour le hachage des objets est la suivante :
- Sauf si
__eq__est surchargée, l'égalité des objets est définie par l'identité, et le hachage correspond à l'identité de l'objet. - Si
__eq__est surchargée, et__hash__ne l'est pas, alors le hachage est bloqué par défaut (parce que la mutabilité qui affecte le résultat d'un contrôle d'égalité briserait les invariants de hachage) ; la réactivation du hachage nécessite la mise en œuvre de l'option__hash__qui dit implicitement "Ma sémantique d'égalité et de hachage est stable/consistante dans le temps", mais n'exige pas que les choses non liées à l'égalité ou au code de hachage soient stables.
Le point est, la condition pour le hachage n'est pas l'immuabilité, c'est la cohérence avec l'égalité (et la stabilité implicite de l'égalité et du hachage). Puisque la plupart des itérateurs et tous les générateurs n'implémentent pas la fonction __eq__ (il n'y a aucun moyen significatif de l'implémenter sans épuiser l'itérateur et perdre les informations que vous venez d'utiliser pour le comparer), tout est basé sur l'identité, comme avec n'importe quel objet défini par l'utilisateur qui ne définit pas l'égalité.
Ofer Sadan
Points
3865
Bien que l'état interne du générateur puisse changer, le générateur dans son ensemble ne peut jamais ajouter quelque chose à lui-même, et ne peut jamais revenir en arrière en itérant sur lui. Par conséquent, un générateur est un objet fixe immuable, ce qui est presque la définition d'être hachable.
Mais encore plus profondément que cela, même les objets mutables peuvent être hachables tant qu'ils définissent __hash__ comme méthode d'instance, mais cela est rarement souhaitable pour les objets mutables.
