Add more common interfaces

[jamadden]

Derived automatically from Python stdlib ABCs.

When done, this will fix #138.

So far, its just the collection classes. Remaining items:

• Whoops, I missed ByteString
• The numbers ABCs
• Other common non-ABC types, like IText and whatever else is missing from dolmen.builtins
• What happens to the "legacy" interfaces in mapping.py and sequence.py? Are they left completely alone? They are probably badly out of date. Do we docs-deprecate them? Maybe they can slot-in as super-classes

[jamadden]

This still leaves classes in control of what interfaces they implement, unlike the virtual duck-typed subclassing of ABCs, as described in #135

It gets us most of the way there, though. If we want to do it, it's now pretty easy with a small change to the definition of implementedBy (and maybe a corresponding tweak to ABCInterface.providedBy for direct queries; not shown here):

-------------------------------------------------------------------------------------------------
modified: src/zope/interface/declarations.py
-------------------------------------------------------------------------------------------------
@@ -275,6 +275,27 @@ def _implements_name(ob):
     return (getattr(ob, '__module__', '?') or '?') + \
         '.' + (getattr(ob, '__name__', '?') or '?')

+def _abc_interfaces():
+    try:
+        from zope.interface.common import ABCInterface, ABCInterfaceClass
+    except ImportError:
+        return [] # Circular imports at _wire() time.
+    from zope.interface.common import collections, numbers, io # Ensure defined
+
+    seen = set()
+    to_examine = list(ABCInterface.dependents)
+    while to_examine:
+        iface = to_examine.pop()
+        if iface in seen:
+            continue
+        seen.add(iface)
+        to_examine.extend(iface.dependents)
+    return [x for x in seen if isinstance(x, ABCInterfaceClass)]
+
+def _abc_interfaces_of(cls):
+    ifaces = _abc_interfaces()
+
+    return [iface for iface in ifaces if issubclass(cls, iface.getABC())]

 @_use_c_impl
 def implementedBy(cls):
@@ -338,7 +359,8 @@ def implementedBy(cls):
                 raise TypeError("ImplementedBy called for non-factory", cls)
             bases = ()

-        spec = Implements.named(spec_name, *[implementedBy(c) for c in bases])
+        spec = Implements.named(spec_name,
+                                *([implementedBy(c) for c in bases] + _abc_interfaces_of(cls)))
         spec.inherit = cls

     try:

With that change, classes that "subclass" ABCs automatically also provide those interfaces:

>>> from zope.interface.common import collections
>>> class Sized(object):
   ...:     def __len__(self): return 0
   ...:
>>> from zope.interface import providedBy
>>> list(providedBy(Sized()))
[<ABCInterfaceClass zope.interface.common.collections.IHashable>,
 <ABCInterfaceClass zope.interface.common.collections.ISized>]

That's a rough approximation, of course. The biggest issue is later registrations and cache invalidations. E.g., this doesn't do what you'd expect:

>>> class VirtualSized(object):
...     pass
...
>>> list(providedBy(VirtualSized()))
[<ABCInterfaceClass zope.interface.common.collections.IHashable>]
>>> from collections.abc import Sized
>>> Sized.register(VirtualSized)
<class '__main__.VirtualSized'>
>>> isinstance(VirtualSized(), Sized)
True
>>> list(providedBy(VirtualSized()))
[<ABCInterfaceClass zope.interface.common.collections.IHashable>]

I feel like that's solvable, though.

Is that something we want to proceed with? I'm not sure I personally have a defined use-case for it right now, but OTOH, I think I remember writing things like classImplements(OOBTree, IMapping); classImplements(dict, IMapping) just to be able to use the same adapters for both OOBTree and dict, and this would make that much more convenient (except for some reason, OOBTree isn't actually a virtual subclass of collections.abc.Mapping 😞 zopefoundation/BTrees#121).

[jensens]

Overall this looks fine. I must admit, I can not judge every detail.

[jamadden]

Thanks for the feedback!

[ale-rt]

LGTM, but maybe wait for @mgedmin review or some other experienced dev!

[mgedmin]

This is rather a big diff and I'm not feeling up to reviewing it right now.

(Lack of review from little old me should not be a blocker to merging!)

[jamadden]

This is rather a big diff and I'm not feeling up to reviewing it right now.

No worries! Thank you.

I will go ahead and merge as I'd like to make a release soon. Since it's completely opt-in I don't think it can do any harm.