"Interface.__eq__" ignores the "Interface" semantics and renders dynamic interface definitions unreliable

[d-maurer]

Interface.__eq__ is only based on __name__ and __module__. This results in a very surprising notion of equality as the following code demonstrates:

>>> from zope.interface import Interface
>>> class I(Interface):
...   def f(): pass
... 
>>> I1 = I
>>> class I: pass
... 
>>> I1 == I
True

i.e. the interface I1 is considered equal to the "normal" (non Interface) class I.

This renders local (i.e. in a function body) interface definitions unreliable as
#216 (comment)
(and following comments) demonstrates. The resulting errors can be non-deterministic and very difficult to analyze.

@jamadden explains in #216 that __eq__ is defined as it is in order to allow interfaces to be used as keys in BTrees. This may justify the definition however due to the potentially very difficult errors which may result from local interface definitions it should be clearly documented (which currently is not the case) with a big warning regarding the implication for local interface definitions (or overridden interface definitions as in the example above).

[jensens]

Taking into account that hashing and equality are called very very often in the code, I am also +1 for good documentation but keeping the current state of implementation. Performance wise it works fine.

[jamadden]

Because the example is unrealistic, ignores pickling/persistence, only results in problems in extremely rare corner cases, and has been the status quo for a decade, I do not consider this to be a significant problem.

I consider the existing documentation adequate. I feel there is no need for "a big warning."

[jensens]

I would not add a big warning, just I think it would be good to mention explicit that (like in the context of mocking for testing):

class A1:
    def a1():
        class IA(Interface):
            pass

class A2:
    def a2():
        class IA(Interface):
            pass

will let you run into problems.

[d-maurer]

Jason Madden wrote at 2020-10-1 03:22 -0700:

Because the example is unrealistic, ignores pickling/persistence, only results in problems in extremely rare corner cases, and has been the status quo for a decade, I do not consider this to be a significant problem. I consider [the existing documentation](https://zopeinterface.readthedocs.io/en/latest/api/specifications.html#equality-hashing-and-comparisons) adequate. I feel there is no need for "a big warning."

You seem to disregard that the problem has occured in a real (test) case and that is was difficult to analyze. I am always very wary about problems that can occur apparently non deterministically -- in the case above, the problem was observed only for one Python version and apparently depended on when the garbage collector became active. Such problems can require an huge amount of analysis effort and should (in my view) be avoided whenever possible.

[d-maurer]

The Interface (more generally Specification) equality definition and its potential caveats are now covered by the (upcoming) documentation (--> #220).