Package: zope.interface
zope.interfaceThis package is intended to be independently reusable in any Python
project. It is maintained by theZope Toolkit project.This package provides an implementation of “object interfaces” for Python.
Interfaces are a mechanism for labeling objects as conforming to a given
API or contract. So, this package can be considered as implementation of
theDesign By Contractmethodology support in Python.For detailed documentation, please seehttps://zopeinterface.readthedocs.io/en/latest/Changes6.2 (2024-02-16)Add preliminary support for Python 3.13 as of 3.13a3.Add support to use the pipe (|) syntax fortyping.Union.
(#280)6.1 (2023-10-05)Build Linux binary wheels for Python 3.12.Add support for Python 3.12.Fix building of the docs for non-final versions.6.0 (2023-03-17)Build Linux binary wheels for Python 3.11.Drop support for Python 2.7, 3.5, 3.6.Fix test deprecation warning on Python 3.11.Add preliminary support for Python 3.12 as of 3.12a5.Drop:zope.interface.implementszope.interface.implementsOnlyzope.interface.classProvides5.5.2 (2022-11-17)Add support for building arm64 wheels on macOS.5.5.1 (2022-11-03)Add support for final Python 3.11 release.5.5.0 (2022-10-10)Add support for Python 3.10 and 3.11 (as of 3.11.0rc2).Add missing Trove classifier showing support for Python 3.9.Add some more entries tozope.interface.interfaces.__all__.Disable unsafe math optimizations in C code.  Seepull request 262.5.4.0 (2021-04-15)Make the C implementation of the__providedBy__descriptor stop
ignoring all errors raised when accessing the instance’s__provides__. Now it behaves like the Python version and only
catchesAttributeError. The previous behaviour could lead to
crashing the interpreter in cases of recursion and errors. Seeissue 239.Update therepr()andstr()of various objects to be shorter
and more informative. In many cases, therepr()is now something
that can be evaluated to produce an equal object. For example, what
was previously printed as<implementedBy builtins.list>is now
shown asclassImplements(list, IMutableSequence, IIterable). Seeissue 236.MakeDeclaration.__add__(as inimplementedBy(Cls) + ISomething) try harder to preserve a consistent resolution order
when the two arguments share overlapping pieces of the interface
inheritance hierarchy. Previously, the right hand side was always
put at the end of the resolution order, which could easily produce
invalid orders. Seeissue 193.5.3.0 (2020-03-21)No changes from 5.3.0a15.3.0a1 (2021-03-18)Improve the repr ofzope.interface.Providesto remove ambiguity
about what is being provided. This is especially helpful diagnosing
IRO issues.Allow subclasses ofBaseAdapterRegistry(includingAdapterRegistryandVerifyingAdapterRegistry) 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). Seeissue 224.Fix a reference counting issue inBaseAdapterRegistrythat 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. Seeissue 227.Add the methodBaseAdapterRegistry.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 methodIAdapterRegistry.subscribed()and
implementationBaseAdapterRegistry.subscribed()for querying
directly registered subscribers. Seeissue 230.Add the maintenance methodComponents.rebuildUtilityRegistryFromLocalCache(). Most users
will not need this, but it can be useful if theComponents.utilitiesregistry is suspected to be out of sync with theComponentsobject itself (this might happen to persistentComponentsimplementations in the face of bugs).Fix theProvidesandClassProvidesdescriptors 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@implementerin 5.1.0, and resolves inconsistent resolution orders withzope.proxyandzope.location. Seeissue 207.5.2.0 (2020-11-05)Add documentation sectionPersistency and Equality(#218).Create arm64 wheels.Add support for Python 3.9.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.  Seepull request 215.5.1.1 (2020-09-30)Fix the method definitions ofIAdapterRegistry.subscribe,subscriptionsandsubscribers. Previously, they all were
defined to accept anamekeyword argument, but subscribers have
no names and the implementation of that interface did not accept
that argument. Seeissue 208.Fix a potential reference leak in the C optimizations. Previously,
applications that dynamically created uniqueSpecificationobjects (e.g., used@implementeron dynamic classes) could
notice a growth of small objects over time leading to increased
garbage collection times. Seeissue 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 thatweakref.refobjects (and things built upon them, likeWeak[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 objectshouldhave been
collected. This could be especially problematic for theWeakKeyDictionarywhen 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 resultingKeyError.Note that such potential errors are not new, they are just once
again a possibility.5.1.0 (2020-04-08)Make@implementer(*iface)andclassImplements(cls, *iface)ignore redundant interfaces. If the class already implements an
interface through inheritance, it is no longer redeclared
specifically forcls. This solves many instances of inconsistent
resolution orders, while still allowing the interface to be declared
for readability and maintenance purposes. Seeissue 199.Remove all bareexcept:statements. Previously, when accessing
special attributes such as__provides__,__providedBy__,__class__and__conform__, this package wrapped such access
in a bareexcept:statement, meaning that many errors could pass
silently; typically this would result in a fallback path being taken
and sometimes (like withprovidedBy()) the result would be
non-sensical. This is especially true when those attributes are
implemented with descriptors. Now, onlyAttributeErroris
caught. This makes errors more obvious.Obviously, this means that some exceptions will be propagated
differently than before. In particular,RuntimeErrorraised by
Acquisition in the case of circular containment will now be
propagated. Previously, when adapting such a broken object, aTypeErrorwould be the common result, but now it will be a more
informativeRuntimeError.In addition, ZODB errors likePOSKeyErrorcould now be
propagated where previously they would ignored by this package.Seeissue 200.Require that the second argument (bases) toInterfaceClassis
a tuple. This only matters when directly usingInterfaceClassto
create new interfaces dynamically. Previously, an individual
interface was allowed, but did not work correctly. Now it is
consistent withtypeand requires a tuple.Let interfaces define custom__adapt__methods. This implements
the other side of thePEP 246adaptation 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@interfacemethoddecorator.Seeissue 3.Make the internal singleton object returned by APIs likeimplementedByanddirectlyProvidedByfor objects that
implement or provide no interfaces more immutable. Previously an
internal cache could be mutated. Seeissue 204.5.0.2 (2020-03-30)Ensure that objects that implement no interfaces (such as direct
subclasses ofobject) still includeInterfaceitself in
their__iro___and__sro___. This fixes adapter registry
lookups for such objects when the adapter is registered forInterface. Seeissue 197.5.0.1 (2020-03-21)Ensure the resolution order forInterfaceClassis consistent.
Seeissue 192.Ensure the resolution order forcollections.OrderedDictis
consistent on CPython 2. (It was already consistent on Python 3 and PyPy).Fix the handling of theZOPE_INTERFACE_STRICT_IROenvironment
variable. Previously,ZOPE_INTERFACE_STRICT_ROwas read, in
contrast with the documentation. Seeissue 194.5.0.0 (2020-03-19)Make an internal singleton object returned by APIs likeimplementedByanddirectlyProvidedByimmutable. Previously,
it was fully mutable and allowed changing its__bases___. That
could potentially lead to wrong results in pathological corner
cases. Seeissue 158.Support thePURE_PYTHONenvironment 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. SeePR 151.Cache the result of__hash__method inInterfaceClassas 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). SeePR 156.Change the C classesSpecificationBaseand its subclassClassProvidesBaseto 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. SeePR 154.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 aWeakKeyDictionaryunless 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 equivalenttp_membersin more
common places. Note that this removes the ability to set arbitrary
instance variables on certain objects.
SeePR 155.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_attrshas changed.Remove support for hashing uninitialized interfaces. This could only
be done by subclassingInterfaceClass. This has generated a
warning since it was first added in 2011 (3.6.5). Please call theInterfaceClassconstructor or otherwise set the appropriate
fields in your subclass before attempting to hash or sort it. Seeissue 157.Remove unneeded override of the__hash__method fromzope.interface.declarations.Implements. Watching a reindex index
process in ZCatalog with on a Py-Spy after 10k samples the time for.adapter._lookupwas reduced from 27.5s to 18.8s (~1.5x faster).
Overall reindex index time shrunk from 369s to 293s (1.26x faster).
SeePR 161.Make the Python implementation closer to the C implementation by
ignoring all exceptions, not justAttributeError, during (parts
of) interface adaptation. Seeissue 163.Micro-optimization in.adapter._lookup,.adapter._lookupAlland.adapter._subscriptions: By loadingcomponents.getinto
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_lookupis ~5x.
SeePR 167.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. Seeissue 153.FixverifyClassandverifyObjectfor builtin types likedictthat have methods taking an optional, unnamed argument with
no default value likedict.pop. On PyPy3, the verification is
strict, but on PyPy2 (as on all versions of CPython) those methods
cannot be verified and are ignored. Seeissue 118.Update the common interfacesIEnumerableMapping,IExtendedReadMapping,IExtendedWriteMapping,IReadSequenceandIUniqueMemberWriteSequenceto no longer
require methods that were removed from Python 3 on Python 3, such as__setslice___. Now,dict,listandtupleproperly
verify asIFullMapping,ISequenceandIReadSequence,respectively on all versions of Python.Add human-readable__str___and__repr___toAttributeandMethod. These contain the name of the defining interface
and the attribute. For methods, it also includes the signature.Change the error strings raised byverifyObjectandverifyClass. They now include more human-readable information
and exclude extraneous lines and spaces. Seeissue 170.Caution!This will break consumers (such as doctests) that
depended on the exact error messages.MakeverifyObjectandverifyClassreport all errors, if the
candidate object has multiple detectable violations. Previously they
reported only the first error. Seeissue.Like the above, this will break consumers depending on the exact
output of error messages if more than one error is present.Addzope.interface.common.collections,zope.interface.common.numbers, andzope.interface.common.io.
These modules define interfaces based on the ABCs defined in the
standard librarycollections.abc,numbersandiomodules, respectively. Importing these modules will make the
standard library concrete classes that are registered with those
ABCs declare the appropriate interface. Seeissue 138.Addzope.interface.common.builtins. This module defines
interfaces of common builtin types, such asITextStringandIByteString,IDict, etc. These interfaces extend the
appropriate interfaces fromcollectionsandnumbers, and the
standard library classes implement them after importing this module.
This is intended as a replacement for third-party packages likedolmen.builtins.
Seeissue 138.MakeprovidedBy()andimplementedBy()respectsuperobjects. For instance, if classDerivedimplementsIDerivedand extendsBasewhich in turn implementsIBase, thenprovidedBy(super(Derived, derived))will return[IBase].
Previously it would have returned[IDerived](in general, it
would previously have returned whatever would have been returned
withoutsuper).Along with this change, adapter registries will unpacksuperobjects into their__self___before passing it to the factory.
Together, this means thatcomponent.getAdapter(super(Derived, self), ITarget)is now meaningful.Seeissue 11.Fix a potential interpreter crash in the low-level adapter
registry lookup functions. See issue 11.Adopt Python’s standardC3 resolution orderto 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 forzope.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. Seeissue 190.AddgetDirectTaggedValue(and related methods) to interfaces to
allow accessing tagged values irrespective of inheritance. Seeissue 190.Ensure thatInterfaceis 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,Interfacecould be assigned too high a priority.
Seeissue 8.Implement sorting, equality, and hashing in C forInterfaceobjects. 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,InterfaceClassnow has a non-default metaclass, and
it is enforced that__module__in instances ofInterfaceClassis read-only.SeePR 183.4.7.2 (2020-03-10)Remove deprecated use of setuptools features.  Seeissue 30.4.7.1 (2019-11-11)Use Python 3 syntax in the documentation.  Seeissue 119.4.7.0 (2019-11-11)Drop support for Python 3.4.ChangequeryTaggedValue,getTaggedValue,getTaggedValueTagsin interfaces. They now include inherited
values by following__bases__. SeePR 144.Caution!This may be a breaking change.Add support for Python 3.8.4.6.0 (2018-10-23)Add support for Python 3.7FixverifyObjectfor class objects with staticmethods on
Python 3. Seeissue 126.4.5.0 (2018-04-19)Drop support for 3.3, avoid accidental dependence breakage via setup.py.
SeePR 110.Allow registering and unregistering instance methods as listeners.
Seeissue 12andPR 102.Synchronize and simplify zope/__init__.py. Seeissue 1144.4.3 (2017-09-22)Avoid exceptions when the__annotations__attribute is added to
interface definitions with Python 3.x type hints. Seeissue 98.Fix the possibility of a rare crash in the C extension when
deallocating items. Seeissue 100.4.4.2 (2017-06-14)Fix a regression storingzope.component.persistentregistry.PersistentRegistryinstances.
Seeissue 85.Fix a regression that could lead to the utility registration cache
ofComponentsgetting out of sync. Seeissue 93.4.4.1 (2017-05-13)Simplify the caching of utility-registration data. In addition to
simplification, avoids spurious test failures when checking for
leaks in tests with persistent registries. Seepull 84.RaiseValueErrorwhen non-text names are passed to adapter registry
methods:  prevents corruption of lookup caches.4.4.0 (2017-04-21)Avoid a warning from the C compiler.
(https://github.com/zopefoundation/zope.interface/issues/71)Add support for Python 3.6.4.3.3 (2016-12-13)Correct typos and ReST formatting errors in documentation.Add API documentation for the adapter registry.Ensure that theLICENSE.txtfile is included in built wheels.Fix C optimizations broken on Py3k.  See the Python bug at:http://bugs.python.org/issue15657(https://github.com/zopefoundation/zope.interface/issues/60)4.3.2 (2016-09-05)Fix equality testing ofimplementedByobjects and proxies.
(https://github.com/zopefoundation/zope.interface/issues/55)4.3.1 (2016-08-31)Support Components subclasses that are not hashable.
(https://github.com/zopefoundation/zope.interface/issues/53)4.3.0 (2016-08-31)Add the ability to sort the objects returned byimplementedBy.
This is compatible with the way interface classes sort so they can
be used together in ordered containers like BTrees.
(https://github.com/zopefoundation/zope.interface/issues/42)Makesetuptoolsa hard dependency ofsetup.py.
(https://github.com/zopefoundation/zope.interface/issues/13)Change a linear algorithm (O(n)) inComponents.registerUtilityandComponents.unregisterUtilityinto a dictionary lookup (O(1)) for
hashable components. This substantially improves the time taken to
manipulate utilities in large registries at the cost of some
additional memory usage. (https://github.com/zopefoundation/zope.interface/issues/46)4.2.0 (2016-06-10)Add support for Python 3.5Drop support for Python 2.6 and 3.2.4.1.3 (2015-10-05)Fix installation without a C compiler on Python 3.5
(https://github.com/zopefoundation/zope.interface/issues/24).4.1.2 (2014-12-27)Add support for PyPy3.Remove unittest assertions deprecated in Python3.x.Addzope.interface.document.asReStructuredText, which formats the
generated text for an interface using ReST double-backtick markers.4.1.1 (2014-03-19)Add support for Python 3.4.4.1.0 (2014-02-05)Updateboostrap.pyto version 2.2.Add@named(name)declaration, that specifies the component name, so it
does not have to be passed in during registration.4.0.5 (2013-02-28)Fix a bug where a decorated method caused false positive failures onverifyClass().4.0.4 (2013-02-21)Fix a bug that was revealed by porting zope.traversing. During a loop, the
loop body modified a weakref dict causing aRuntimeErrorerror.4.0.3 (2012-12-31)Fleshed out PyPI Trove classifiers.4.0.2 (2012-11-21)Add support for Python 3.3.Restored ability to install the package in the absence ofsetuptools.LP #1055223:  Fix test which depended on dictionary order and failed randomly
in Python 3.3.4.0.1 (2012-05-22)Drop explicitDeprecationWarningsfor “class advice” APIS (these
APIs are still deprecated under Python 2.x, and still raise an exception
under Python 3.x, but no longer cause a warning to be emitted under
Python 2.x).4.0.0 (2012-05-16)Automated build of Sphinx HTML docs and running doctest snippets via tox.Deprecate the “class advice” APIs fromzope.interface.declarations:implements,implementsOnly, andclassProvides.  In their place,
prefer the equivalent class decorators:@implementer,@implementer_only, and@provider.  Code which uses the deprecated
APIs will not work as expected under Py3k.Remove use of ‘2to3’ and associated fixers when installing under Py3k.
The code is now in a “compatible subset” which supports Python 2.6, 2.7,
and 3.2, including PyPy 1.8 (the version compatible with the 2.7 language
spec).Drop explicit support for Python 2.4 / 2.5 / 3.1.Add support for PyPy.Add support for continuous integration usingtoxandjenkins.Add ‘setup.py dev’ alias (runssetup.py developplus installsnoseandcoverage).Add ‘setup.py docs’ alias (installsSphinxand dependencies).Replace all unittest coverage previously accomplished via doctests with
unittests.  The doctests have been moved into adocssection, managed
as a Sphinx collection.LP #910987:  Ensure that the semantics of thelookupmethod ofzope.interface.adapter.LookupBaseare the same in both the C and
Python implementations.LP #900906:  Avoid exceptions due to tne new__qualname__attribute
added in Python 3.3 (see PEP 3155 for rationale).  Thanks to Antoine
Pitrou for the patch.3.8.0 (2011-09-22)New modulezope.interface.registry.  This is code moved fromzope.component.registrywhich implements a basic nonperistent component
registry aszope.interface.registry.Components.  This class was moved
fromzope.componentto make porting systems (such as Pyramid) that rely
only on a basic component registry to Python 3 possible without needing to
port the entirety of thezope.componentpackage.  Backwards
compatibility import shims have been left behind inzope.component, so
this change will not break any existing code.Newtests_requiredependency:zope.eventto test events sent by
Components implementation.  Thezope.interfacepackage does not have a
hard dependency onzope.event, but ifzope.eventis importable, it
will send component registration events when methods of an instance ofzope.interface.registry.Componentsare called.New interfaces added to supportzope.interface.registry.Componentsaddition:ComponentLookupError,Invalid,IObjectEvent,ObjectEvent,IComponentLookup,IRegistration,IUtilityRegistration,IAdapterRegistration,ISubscriptionAdapterRegistration,IHandlerRegistration,IRegistrationEvent,RegistrationEvent,IRegistered,Registered,IUnregistered,Unregistered,IComponentRegistry, andIComponents.No longer Python 2.4 compatible (tested under 2.5, 2.6, 2.7, and 3.2).3.7.0 (2011-08-13)Move changes from 3.6.2 - 3.6.5 to a new 3.7.x release line.3.6.7 (2011-08-20)Fix sporadic failures on x86-64 platforms in tests of rich comparisons
of interfaces.3.6.6 (2011-08-13)LP #570942:  Now correctly compare interfaces  from different modules but
with the same names.N.B.: This is a less intrusive / destabilizing fix than the one applied in
3.6.3:  we only fix the underlying cmp-alike function, rather than adding
the other “rich comparison” functions.Revert to software as released with 3.6.1 for “stable” 3.6 release branch.3.6.5 (2011-08-11)LP #811792:  work around buggy behavior in some subclasses ofzope.interface.interface.InterfaceClass, which invoke__hash__before initializing__module__and__name__.  The workaround
returns a fixed constant hash in such cases, and issues aUserWarning.LP #804832:  Under PyPy,zope.interfaceshould not build its C
extension.  Also, prevent attempting to build it under Jython.Add a tox.ini for easier xplatform testing.Fix testing deprecation warnings issued when tested under Py3K.3.6.4 (2011-07-04)LP 804951:  InterfaceClass instances were unhashable under Python 3.x.3.6.3 (2011-05-26)LP #570942:  Now correctly compare interfaces  from different modules but
with the same names.3.6.2 (2011-05-17)Moved detailed documentation out-of-line from PyPI page, linking instead tohttp://docs.zope.org/zope.interface.Fixes for small issues when running tests under Python 3.2 usingzope.testrunner.LP # 675064:  Specify return value type for C optimizations module init
under Python 3:  undeclared value caused warnings, and segfaults on some
64 bit architectures.setup.py now raises RuntimeError if you don’t have Distutils installed when
running under Python 3.3.6.1 (2010-05-03)A non-ASCII character in the changelog made 3.6.0 uninstallable on
Python 3 systems with another default encoding than UTF-8.Fix compiler warnings under GCC 4.3.3.3.6.0 (2010-04-29)LP #185974:  Clear the cache used bySpecificaton.getinsideSpecification.changed.  Thanks to Jacob Holm for the patch.Add support for Python 3.1. Contributors:Lennart Regebro
Martin v Loewis
Thomas Lotze
Wolfgang SchnerringThe 3.1 support is completely backwards compatible. However, the implements
syntax used under Python 2.X does not work under 3.X, since it depends on
how metaclasses are implemented and this has changed. Instead it now supports
a decorator syntax (also under Python 2.X):class Foo:
    implements(IFoo)
    ...can now also be written:@implementer(IFoo):
class Foo:
    ...There are 2to3 fixers available to do this change automatically in the
zope.fixers package.Python 2.3 is no longer supported.3.5.4 (2009-12-23)Use the standard Python doctest module instead of zope.testing.doctest, which
has been deprecated.3.5.3 (2009-12-08)Fix an edge case: make providedBy() work when a class has ‘__provides__’ in
its __slots__ (seehttp://thread.gmane.org/gmane.comp.web.zope.devel/22490)3.5.2 (2009-07-01)BaseAdapterRegistry.unregister, unsubscribe: Remove empty portions of
the data structures when something is removed.  This avoids leaving
references to global objects (interfaces) that may be slated for
removal from the calling application.3.5.1 (2009-03-18)verifyObject: use getattr instead of hasattr to test for object attributes
in order to let exceptions other than AttributeError raised by properties
propagate to the callerAdd Sphinx-based documentation building to the package buildout
configuration. Use thebin/docscommand after buildout.Improve package description a bit. Unify changelog entries formatting.Change package’s mailing list address to zope-dev at zope.org as
zope3-dev at zope.org is now retired.3.5.0 (2008-10-26)Fix declaration of _zope_interface_coptimizations, it’s not a top level
package.Add a DocTestSuite for odd.py module, so their tests are run.Allow to bootstrap on Jython.Fixhttps://bugs.launchpad.net/zope3/3.3/+bug/98388: ISpecification
was missing a declaration for __iro__.Add optional code optimizations support, which allows the building
of C code optimizations to fail (Jython).Replace_flattenwith a non-recursive implementation, effectively making
it 3x faster.3.4.1 (2007-10-02)Fix a setup bug that prevented installation from source on systems
without setuptools.3.4.0 (2007-07-19)Final release for 3.4.0.3.4.0b3 (2007-05-22)When checking whether an object is already registered, use identity
comparison, to allow adding registering with picky custom comparison methods.3.3.0.1 (2007-01-03)Made a reference to OverflowWarning, which disappeared in Python
2.5, conditional.3.3.0 (2007/01/03)New FeaturesRefactor the adapter-lookup algorithim to make it much simpler and faster.Also, implement more of the adapter-lookup logic in C, making
debugging of application code easier, since there is less
infrastructre code to step through.Treat objects without interface declarations as if they
declared that they providezope.interface.Interface.Add a number of richer new adapter-registration interfaces
that provide greater control and introspection.Add a new interface decorator to zope.interface that allows the
setting of tagged values on an interface at definition time (see
zope.interface.taggedValue).Bug FixesA bug in multi-adapter lookup sometimes caused incorrect adapters to
be returned.3.2.0.2 (2006-04-15)Fix packaging bug:  ‘package_dir’ must be arelativepath.3.2.0.1 (2006-04-14)Packaging change:  suppress inclusion of ‘setup.cfg’ in ‘sdist’ builds.3.2.0 (2006-01-05)Corresponds to the version of the zope.interface package shipped as part of
the Zope 3.2.0 release.3.1.0 (2005-10-03)Corresponds to the version of the zope.interface package shipped as part of
the Zope 3.1.0 release.Made attribute resolution order consistent with component lookup order,
i.e. new-style class MRO semantics.Deprecate ‘isImplementedBy’ and ‘isImplementedByInstancesOf’ APIs in
favor of ‘implementedBy’ and ‘providedBy’.3.0.1 (2005-07-27)Corresponds to the version of the zope.interface package shipped as part of
the Zope X3.0.1 release.Fix a bug reported by James Knight, which caused adapter registries
to fail occasionally to reflect declaration changes.3.0.0 (2004-11-07)Corresponds to the version of the zope.interface package shipped as part of
the Zope X3.0.0 release.