-
Notifications
You must be signed in to change notification settings - Fork 71
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
Comments
I think it probably should, especially since we made a similar change in #199 for 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. |
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>`_.
(Taken from #199 (comment))
#203 lets most of zopetoolkit's tests run in STRICT_IRO mode. There are a few exceptions:
@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.@implementer(Interface)
, which is unnecessary and violates strict IRO. Probably the algorithm here that makes an exception for the sake ofplone.app.caching.tests.test_etags
should be aware of strict mode and not make that exception.Provides(cls, providedBy(proxy))
fails whencls
andproxy
overlap incompatibly in their orders). It makes me wonder ifProvides()
should automatically do the same thing that zope.container is currently manually doing?The text was updated successfully, but these errors were encountered: