Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remaining issues with strict IRO in zopetoolkit #207

Open
jamadden opened this issue Apr 8, 2020 · 1 comment
Open

Remaining issues with strict IRO in zopetoolkit #207

jamadden opened this issue Apr 8, 2020 · 1 comment

Comments

@jamadden
Copy link
Member

jamadden commented Apr 8, 2020

(Taken from #199 (comment))

#203 lets most of zopetoolkit's tests run in STRICT_IRO mode. There are a few exceptions:

  • ZODB's FileStorage redundantly declares multiple implemented interfaces. The fix is easy:
 @implementer(
-        IStorage,
         IStorageRestoreable,
         IStorageIteration,
         IStorageUndoable,

but…there's code in @implementer that attempts to detect things like that which should have caught and corrected it. I don't understand why it didn't work and need to investigate.

  • zope.session.http.CookieClientIdManager has a nearly identical issue.
  • zope.viewlet and zope.lifecycleevent both have the same issue in README.rst where some object is declared to @implementer(Interface), which is unnecessary and violates strict IRO. Probably the algorithm here that makes an exception for the sake of plone.app.caching.tests.test_etags should be aware of strict mode and not make that exception.
  • zope.location is being hit with DecoratorSpecificationDescriptor produces inconsistent resolution orders zope.proxy#41, which is the same issue zope.container recently fixed (Provides(cls, providedBy(proxy)) fails when cls and proxy overlap incompatibly in their orders). It makes me wonder if Provides() should automatically do the same thing that zope.container is currently manually doing?
@jamadden
Copy link
Member Author

jamadden commented Mar 16, 2021

zope.location is being hit with zopefoundation/zope.proxy#41, which is the same issue zope.container recently fixed (Provides(cls, providedBy(proxy)) fails when cls and proxy overlap incompatibly in their orders). It makes me wonder if Provides() should automatically do the same thing that zope.container is currently manually doing?

I think it probably should, especially since we made a similar change in #199 for @implementer and classProvides.

Doing the following lets the zope.location tests run in strict mode, and doesn't break any tests in zope.interface.

@@ -747,7 +747,13 @@ class Provides(Declaration):  # Really named ProvidesClass
     def __init__(self, cls, *interfaces):
         self.__args = (cls, ) + interfaces
         self._cls = cls
-        Declaration.__init__(self, *(interfaces + (implementedBy(cls), )))
+        implemented_by_cls = implementedBy(cls)
+        interfaces = tuple([
+            iface
+            for iface in interfaces
+            if not implemented_by_cls.isOrExtends(iface)
+        ])
+        Declaration.__init__(self, *(interfaces + (implemented_by_cls,)))

The zope.proxy tests run either way.

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Apr 14, 2021
5.3.0 (2020-03-21)
==================

- No changes from 5.3.0a1


5.3.0a1 (2021-03-18)
====================

- Improve the repr of ``zope.interface.Provides`` to remove ambiguity
  about what is being provided. This is especially helpful diagnosing
  IRO issues.

- Allow subclasses of ``BaseAdapterRegistry`` (including
  ``AdapterRegistry`` and ``VerifyingAdapterRegistry``) to have
  control over the data structures. This allows persistent
  implementations such as those based on ZODB to choose more scalable
  options (e.g., BTrees instead of dicts). See `issue 224
  <https://github.com/zopefoundation/zope.interface/issues/224>`_.

- Fix a reference counting issue in ``BaseAdapterRegistry`` that could
  lead to references to interfaces being kept around even when all
  utilities/adapters/subscribers providing that interface have been
  removed. This is mostly an issue for persistent implementations.
  Note that this only corrects the issue moving forward, it does not
  solve any already corrupted reference counts. See `issue 227
  <https://github.com/zopefoundation/zope.interface/issues/227>`_.

- Add the method ``BaseAdapterRegistry.rebuild()``. This can be used
  to fix the reference counting issue mentioned above, as well as to
  update the data structures when custom data types have changed.

- Add the interface method ``IAdapterRegistry.subscribed()`` and
  implementation ``BaseAdapterRegistry.subscribed()`` for querying
  directly registered subscribers. See `issue 230
  <https://github.com/zopefoundation/zope.interface/issues/230>`_.

- Add the maintenance method
  ``Components.rebuildUtilityRegistryFromLocalCache()``. Most users
  will not need this, but it can be useful if the ``Components.utilities``
  registry is suspected to be out of sync with the ``Components``
  object itself (this might happen to persistent ``Components``
  implementations in the face of bugs).

- Fix the ``Provides`` and ``ClassProvides`` descriptors to stop
  allowing redundant interfaces (those already implemented by the
  underlying class or meta class) to produce an inconsistent
  resolution order. This is similar to the change in ``@implementer``
  in 5.1.0, and resolves inconsistent resolution orders with
  ``zope.proxy`` and ``zope.location``. See `issue 207
  <https://github.com/zopefoundation/zope.interface/issues/207>`_.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant