Interface comparison with emtpy __name__ reports incorrect equality

[thet]

When comparing two different interfaces with the same, empty name they are reported to be equal:

zope.interface version 4.1.3:

>>> from zope.interface import Interface
>>> class A(Interface): pass
... 
>>> class B(Interface): pass
... 
>>> A == B  # correctly repots unquality
False

>>> A.__name__ = ''
>>> B.__name__ = ''
>>> A == B  # equality looks incorrect to me.
True

With zope.interface 3.6.7 the last test returns False, so they are treated as unequal.

Also, the zope.interface.interface.InterfaceClass.__cmp function comment says ( https://github.com/zopefoundation/zope.interface/blob/master/src/zope/interface/interface.py#L490 )

        # Yes, I did mean to name this __cmp, rather than __cmp__.
        # It is a private method used by __lt__ and __gt__.
        # I don't want to override __eq__ because I want the default
        # __eq__, which is really fast.

But the __eq__ function was added with c7a10ce -- the comment should be changed.
Related: https://bugs.launchpad.net/zope.interface/+bug/570942

[thet]

If the interfaces were not in the same module, the comparison would correctly report inequality. I found this issue while fixing a test failure in plone.autoform ( https://github.com/plone/plone.autoform/blob/69702485572cab9e8967698f014a6b079c4834d7/plone/autoform/autoform.txt#L370 ) with latest zope.interface. the test tells, why one would have two interfaces with the same name within the same module space:

It is possible to have interfaces/schema that have an empty __name__
attribute, specifically in some cases where a schema is dynamically
created.  In such cases, it is possible to have a subclass of
AutoExtensibleForm implement a getPrefix() function as a sufficient
condition for group naming when autoGroups is True.

[tseaver]

Assigning an empty __name__ to the interface seems like a bogus use case: such interfaces won't be picklable, for instance. The fact that it somehow used to work as you want now was an accident of implementation, rather than a contract.

[seanupton]

@tseaver @thet FWIW, we use (dynamic) interfaces with empty __name__, serialized to a persistent utility inside ZODB using a content-addressed storage (md5sum of serialization is key for the mapping).

Since we cannot pickle references to these, we use ObjectSpecificationDescriptor subclass on content "signed" with the md5sum of the serialization of the interface.

The primary reason we have an empty __name__, is that you (a) plone.supermodel serialization includes interface name in its XML output; (b) mathematically impossible (in general) to have content-addressed name inside the content being addressed by a hash of itself.

[tseaver]

@seanupton I'm sorry, but your description confused me. I'll re-open to allow discussion to continue.

[seanupton]

My sense is that my empty __name__ case is valid, but definitely a corner-case.

@thet has a work-around in the doctest of plone.autoform, so I am not concerned about equivalence essentially based on (__module__, __name__) failing here. My sense is that this can be closed again; it is not worth making so much effort to accommodate my corner case, though I hope @thet will humor the need for the doctest adjustment he made for plone.autoform to help me out here.

My need to do this largely works around the particulars of how I am storing and identifying interfaces (specific to using plone.supermodel serialization to XML, particular to the way plone.supermodel serializes the name, and particular to the fact that my use of plone.alterego for dynamic resolution of an identifier that cannot be serialized in that XML) [1].

[1] My application "signs" objects using the md5sum of the schema serialization, and use that signature to look up (and load from ZODB, import into a dynamic module with an identifier based on the md5sum) the schema we need at run time. This works well for my use-case, but I am quite certain I am the only party in the known universe doing this

[tseaver]

My sense is that this can be closed again; it is not worth making so much effort to accommodate my corner case,

Thanks, @seanupton.