Log message:
py-ZopeInterface: updated to 5.3.0

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>`_.

Log message:
py-ZopeInterface: updated to 5.2.0

5.2.0:
- Add documentation section ``Persistency and Equality``
- Create arm64 wheels.
- Add support for Python 3.9.

Log message:
py-ZopeInterface: updated to 5.1.2

5.1.2 (2020-10-01)
==================

- Make sure to call each invariant only once when validating invariants.
  Previously, invariants could be called multiple times because when an
  invariant is defined in an interface, it's found by in all interfaces
  inheriting from that interface.  See `pull request 215
  <https://github.com/zopefoundation/zope.interface/pull/215/>`_.

5.1.1 (2020-09-30)
==================

- Fix the method definitions of ``IAdapterRegistry.subscribe``,
  ``subscriptions`` and ``subscribers``. Previously, they all were
  defined to accept a ``name`` keyword argument, but subscribers have
  no names and the implementation of that interface did not accept
  that argument. See `issue 208
  <https://github.com/zopefoundation/zope.interface/issues/208>`_.

- Fix a potential reference leak in the C optimizations. Previously,
  applications that dynamically created unique ``Specification``
  objects (e.g., used ``@implementer`` on dynamic classes) could
  notice a growth of small objects over time leading to increased
  garbage collection times. See `issue 216
  <https://github.com/zopefoundation/zope.interface/issues/216>`_.

  .. caution::

     This leak could prevent interfaces used as the bases of
     other interfaces from being garbage collected. Those interfaces
     will now be collected.

     One way in which this would manifest was that ``weakref.ref``
     objects (and things built upon them, like
     ``Weak[Key|Value]Dictionary``) would continue to have access to
     the original object even if there were no other visible
     references to Python and the original object *should* have been
     collected. This could be especially problematic for the
     ``WeakKeyDictionary`` when combined with dynamic or local
     (created in the scope of a function) interfaces, since interfaces
     are hashed based just on their name and module name. See the
     linked issue for an example of a resulting ``KeyError``.

     Note that such potential errors are not new, they are just once
     again a possibility.

Log message:
*: switch to versioned_dependencies.mk for py-setuptools

Log message:
py-ZopeInterface: updated to 5.1.0

5.1.0:

- Make ``@implementer(*iface)`` and ``classImplements(cls, *iface)``
  ignore redundant interfaces. If the class already implements an
  interface through inheritance, it is no longer redeclared
  specifically for *cls*. This solves many instances of inconsistent
  resolution orders, while still allowing the interface to be declared
  for readability and maintenance purposes.

- Remove all bare ``except:`` statements. Previously, when accessing
  special attributes such as ``__provides__``, ``__providedBy__``,
  ``__class__`` and ``__conform__``, this package wrapped such access
  in a bare ``except:`` statement, meaning that many errors could pass
  silently; typically this would result in a fallback path being taken
  and sometimes (like with ``providedBy()``) the result would be
  non-sensical. This is especially true when those attributes are
  implemented with descriptors. Now, only ``AttributeError`` is
  caught. This makes errors more obvious.

  Obviously, this means that some exceptions will be propagated
  differently than before. In particular, ``RuntimeError`` raised by
  Acquisition in the case of circular containment will now be
  propagated. Previously, when adapting such a broken object, a
  ``TypeError`` would be the common result, but now it will be a more
  informative ``RuntimeError``.

  In addition, ZODB errors like ``POSKeyError`` could now be
  propagated where previously they would ignored by this package.

- Require that the second argument (*bases*) to ``InterfaceClass`` is
  a tuple. This only matters when directly using ``InterfaceClass`` to
  create new interfaces dynamically. Previously, an individual
  interface was allowed, but did not work correctly. Now it is
  consistent with ``type`` and requires a tuple.

- Let interfaces define custom ``__adapt__`` methods. This implements
  the other side of the :pep:`246` adaptation protocol: objects being
  adapted could already implement ``__conform__`` if they know about
  the interface, and now interfaces can implement ``__adapt__`` if
  they know about particular objects. There is no performance penalty
  for interfaces that do not supply custom ``__adapt__`` methods.

  This includes the ability to add new methods, or override existing
  interface methods using the new ``@interfacemethod`` decorator.

- Make the internal singleton object returned by APIs like
  ``implementedBy`` and ``directlyProvidedBy`` for objects that
  implement or provide no interfaces more immutable. Previously an
  internal cache could be mutated.

5.0.2:

- Ensure that objects that implement no interfaces (such as direct
  subclasses of ``object``) still include ``Interface`` itself in
  their ``__iro___`` and ``__sro___``. This fixes adapter registry
  lookups for such objects when the adapter is registered for
  ``Interface``.

5.0.1:

- Ensure the resolution order for ``InterfaceClass`` is consistent.

- Ensure the resolution order for ``collections.OrderedDict`` is
  consistent on CPython 2. (It was already consistent on Python 3 and PyPy).

- Fix the handling of the ``ZOPE_INTERFACE_STRICT_IRO`` environment
  variable. Previously, ``ZOPE_INTERFACE_STRICT_RO`` was read, in
  contrast with the documentation.

5.0.0:

- Make an internal singleton object returned by APIs like
  ``implementedBy`` and ``directlyProvidedBy`` immutable. Previously,
  it was fully mutable and allowed changing its ``__bases___``. That
  could potentially lead to wrong results in pathological corner
  cases.

- Support the ``PURE_PYTHON`` environment variable at runtime instead
  of just at wheel build time. A value of 0 forces the C extensions to
  be used (even on PyPy) failing if they aren't present. Any other
  value forces the Python implementation to be used, ignoring the C
  extensions.

- Cache the result of ``__hash__`` method in ``InterfaceClass`` as a
  speed optimization. The method is called very often (i.e several
  hundred thousand times during Plone 5.2 startup). Because the hash value never
  changes it can be cached. This improves test performance from 0.614s
  down to 0.575s (1.07x faster). In a real world Plone case a reindex
  index came down from 402s to 320s (1.26x faster).

- Change the C classes ``SpecificationBase`` and its subclass
  ``ClassProvidesBase`` to store implementation attributes in their structures
  instead of their instance dictionaries. This eliminates the use of
  an undocumented private C API function, and helps make some
  instances require less memory.

- Reduce memory usage in other ways based on observations of usage
  patterns in Zope (3) and Plone code bases.

  - Specifications with no dependents are common (more than 50%) so
    avoid allocating a ``WeakKeyDictionary`` unless we need it.
  - Likewise, tagged values are relatively rare, so don't allocate a
    dictionary to hold them until they are used.
  - Use ``__slots___`` or the C equivalent ``tp_members`` in more
    common places. Note that this removes the ability to set arbitrary
    instance variables on certain objects.

  The changes in this release resulted in a 7% memory reduction after
  loading about 6,000 modules that define about 2,200 interfaces.

  .. caution::

     Details of many private attributes have changed, and external use
     of those private attributes may break. In particular, the
     lifetime and default value of ``_v_attrs`` has changed.

- Remove support for hashing uninitialized interfaces. This could only
  be done by subclassing ``InterfaceClass``. This has generated a
  warning since it was first added in 2011 (3.6.5). Please call the
  ``InterfaceClass`` constructor or otherwise set the appropriate
  fields in your subclass before attempting to hash or sort it.

- Remove unneeded override of the ``__hash__`` method from
  ``zope.interface.declarations.Implements``. Watching a reindex index
  process in ZCatalog with on a Py-Spy after 10k samples the time for
  ``.adapter._lookup`` was reduced from 27.5s to 18.8s (~1.5x faster).
  Overall reindex index time shrunk from 369s to 293s (1.26x faster).

- Make the Python implementation closer to the C implementation by
  ignoring all exceptions, not just ``AttributeError``, during (parts
  of) interface adaptation.

- Micro-optimization in ``.adapter._lookup`` , ``.adapter._lookupAll``
  and ``.adapter._subscriptions``: By loading ``components.get`` into
  a local variable before entering the loop a bytcode "LOAD_FAST 0
  (components)" in the loop can be eliminated. In Plone, while running
  all tests, average speedup of the "owntime" of ``_lookup`` is ~5x.

- Add ``__all__`` declarations to all modules. This helps tools that
  do auto-completion and documentation and results in less cluttered
  results. Wildcard ("*") are not recommended and may be affected.

- Fix ``verifyClass`` and ``verifyObject`` for builtin types like
  ``dict`` that have methods taking an optional, unnamed argument with
  no default value like ``dict.pop``. On PyPy3, the verification is
  strict, but on PyPy2 (as on all versions of CPython) those methods
  cannot be verified and are ignored.

- Update the common interfaces ``IEnumerableMapping``,
  ``IExtendedReadMapping``, ``IExtendedWriteMapping``,
  ``IReadSequence`` and ``IUniqueMemberWriteSequence`` to no longer
  require methods that were removed from Python 3 on Python 3, such as
  ``__setslice___``. Now, ``dict``, ``list`` and ``tuple`` properly
  verify as ``IFullMapping``, ``ISequence`` and ``IReadSequence,``
  respectively on all versions of Python.

- Add human-readable ``__str___`` and ``__repr___`` to ``Attribute``
  and ``Method``. These contain the name of the defining interface
  and the attribute. For methods, it also includes the signature.

- Change the error strings raised by ``verifyObject`` and
  ``verifyClass``. They now include more human-readable information
  and exclude extraneous lines and spaces.

  .. caution:: This will break consumers (such as doctests) that
               depended on the exact error messages.

- Make ``verifyObject`` and ``verifyClass`` report all errors, if the
  candidate object has multiple detectable violations. Previously they
  reported only the first error.

  Like the above, this will break consumers depending on the exact
  output of error messages if more than one error is present.

- Add ``zope.interface.common.collections``,
  ``zope.interface.common.numbers``, and ``zope.interface.common.io``.
  These modules define interfaces based on the ABCs defined in the
  standard library ``collections.abc``, ``numbers`` and ``io``
  modules, respectively. Importing these modules will make the
  standard library concrete classes that are registered with those
  ABCs declare the appropriate interface.

- Add ``zope.interface.common.builtins``. This module defines
  interfaces of common builtin types, such as ``ITextString`` and
  ``IByteString``, ``IDict``, etc. These interfaces extend the
  appropriate interfaces from ``collections`` and ``numbers``, and the
  standard library classes implement them after importing this module.
  This is intended as a replacement for third-party packages like
  `dolmen.builtins <https://pypi.org/project/dolmen.builtins/>`_.

- Make ``providedBy()`` and ``implementedBy()`` respect ``super``
  objects. For instance, if class ``Derived`` implements ``IDerived``
  and extends ``Base`` which in turn implements ``IBase``, then
  ``providedBy(super(Derived, derived))`` will return ``[IBase]``.
  Previously it would have returned ``[IDerived]`` (in general, it
  would previously have returned whatever would have been returned
  without ``super``).

  Along with this change, adapter registries will unpack ``super``
  objects into their ``__self___`` before passing it to the factory.
  Together, this means that ``component.getAdapter(super(Derived,
  self), ITarget)`` is now meaningful.

- Fix a potential interpreter crash in the low-level adapter
  registry lookup functions.

- Adopt Python's standard `C3 resolution order
  <https://www.python.org/download/releases/2.3/mro/>`_ to compute the
  ``__iro__`` and ``__sro__`` of interfaces, with tweaks to support
  additional cases that are common in interfaces but disallowed for
  Python classes. Previously, an ad-hoc ordering that made no
  particular guarantees was used.

  This has many beneficial properties, including the fact that base
  interface and base classes tend to appear near the end of the
  resolution order instead of the beginning. The resolution order in
  general should be more predictable and consistent.

  .. caution::
     In some cases, especially with complex interface inheritance
     trees or when manually providing or implementing interfaces, the
     resulting IRO may be quite different. This may affect adapter
     lookup.

  The C3 order enforces some constraints in order to be able to
  guarantee a sensible ordering. Older versions of zope.interface did
  not impose similar constraints, so it was possible to create
  interfaces and declarations that are inconsistent with the C3
  constraints. In that event, zope.interface will still produce a
  resolution order equal to the old order, but it won't be guaranteed
  to be fully C3 compliant. In the future, strict enforcement of C3
  order may be the default.

  A set of environment variables and module constants allows
  controlling several aspects of this new behaviour. It is possible to
  request warnings about inconsistent resolution orders encountered,
  and even to forbid them. Differences between the C3 resolution order
  and the previous order can be logged, and, in extreme cases, the
  previous order can still be used (this ability will be removed in
  the future). For details, see the documentation for
  ``zope.interface.ro``.

- Make inherited tagged values in interfaces respect the resolution
  order (``__iro__``), as method and attribute lookup does. Previously
  tagged values could give inconsistent results.

- Add ``getDirectTaggedValue`` (and related methods) to interfaces to
  allow accessing tagged values irrespective of inheritance.

- Ensure that ``Interface`` is always the last item in the ``__iro__``
  and ``__sro__``. This is usually the case, but if classes that do
  not implement any interfaces are part of a class inheritance
  hierarchy, ``Interface`` could be assigned too high a priority.

- Implement sorting, equality, and hashing in C for ``Interface``
  objects. In micro benchmarks, this makes those operations 40% to 80%
  faster. This translates to a 20% speed up in querying adapters.

  Note that this changes certain implementation details. In
  particular, ``InterfaceClass`` now has a non-default metaclass, and
  it is enforced that ``__module__`` in instances of
  ``InterfaceClass`` is read-only.

Log message:
py-ZopeInterface: updated to 4.6.0

4.6.0:
- Add support for Python 3.7
- Fix verifyObject for class objects with staticmethods on
  Python 3.

Log message:
py-ZopeInterface: updated to 4.5.0

4.5.0:
- Drop support for 3.3, avoid accidental dependence breakage via setup.py.
- Allow registering and unregistering instance methods as listeners.
- Synchronize and simplify zope/__init__.py.

Log message:
py-ZopeInterface: update to 4.4.3

4.4.3:
- Avoid exceptions when the ``__annotations__`` attribute is added to
  interface definitions with Python 3.x type hints.
- Fix the possibility of a rare crash in the C extension when
  deallocating items.

Log message:
Follow some redirects.

Log message:
Updated py-ZopeInterface to 4.4.2.

4.4.2 (2017-06-14)
------------------

- Fix a regression storing
  ``zope.component.persistentregistry.PersistentRegistry`` instances.
  See `issue 85 <https://github.com/zopefoundation/zope.interface/issues/85>`_.

- Fix a regression that could lead to the utility registration cache
  of ``Components`` getting out of sync. See `issue 93
  <https://github.com/zopefoundation/zope.interface/issues/93>`_.