Inkonsistente Implementierung von collections.abc

Question

Ich versuche, collections.abc Quellcode zu verstehen.

Lassen Sie uns auf Hashable Klasse __subclasshook__ Implementierung einen Blick:

@classmethod 
def __subclasshook__(cls, C): 
    if cls is Hashable: 
     for B in C.__mro__: 
      if "__hash__" in B.__dict__: 
       if B.__dict__["__hash__"]: 
        return True 
       break 
    return NotImplemented 

Hier wir zunächst prüfen, ob es Eigentum ist hash und als überprüfen, ob es nicht falsch Wert hat. Diese Logik wird auch in der Klasse Awaitable dargestellt.

Und AsyncIterable Klasse __subclasshook__:

@classmethod 
def __subclasshook__(cls, C): 
    if cls is AsyncIterable: 
     if any("__aiter__" in B.__dict__ for B in C.__mro__): 
      return True 
    return NotImplemented 

Hier stellen wir nur prüfen, ob es __aiter___ Eigenschaft ist, und diese Logik wird in allen anderen Klassen aus diesem Paket präsentiert.

Gibt es einen Grund für diesen logischen Unterschied?

Answer 1

Die __hash__ protocol ermöglicht explizit das Markieren einer Klasse als nicht abspeicherbar, indem __hash__ = None festgelegt wird.

Wenn eine Klasse [...] die Hash-Unterstützung unterdrücken möchte, sollte sie in der Klassendefinition __hash__ = None enthalten.

Der Grund ist, dass a == b immer hash(a) == hash(b) erfordert. Ansonsten brechen dict, set und ähnliche Datenstrukturen. Wenn eine untergeordnete Klasse __eq__ explizit oder auf andere Weise ändert, gilt dies möglicherweise nicht mehr. Daher kann __hash__ als nicht anwendbar gekennzeichnet werden.