Funktionierender Prototyp des Serious Games zur Vermittlung von Wissen zu Software-Engineering-Arbeitsmodellen.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

1 year ago
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108
  1. Metadata-Version: 2.1
  2. Name: zope.interface
  3. Version: 6.0
  4. Summary: Interfaces for Python
  5. Home-page: https://github.com/zopefoundation/zope.interface
  6. Author: Zope Foundation and Contributors
  7. Author-email: zope-dev@zope.org
  8. License: ZPL 2.1
  9. Keywords: interface,components,plugins
  10. Classifier: Development Status :: 5 - Production/Stable
  11. Classifier: Intended Audience :: Developers
  12. Classifier: License :: OSI Approved :: Zope Public License
  13. Classifier: Operating System :: OS Independent
  14. Classifier: Programming Language :: Python
  15. Classifier: Programming Language :: Python :: 3
  16. Classifier: Programming Language :: Python :: 3.7
  17. Classifier: Programming Language :: Python :: 3.8
  18. Classifier: Programming Language :: Python :: 3.9
  19. Classifier: Programming Language :: Python :: 3.10
  20. Classifier: Programming Language :: Python :: 3.11
  21. Classifier: Programming Language :: Python :: Implementation :: CPython
  22. Classifier: Programming Language :: Python :: Implementation :: PyPy
  23. Classifier: Framework :: Zope :: 3
  24. Classifier: Topic :: Software Development :: Libraries :: Python Modules
  25. Requires-Python: >=3.7
  26. License-File: LICENSE.txt
  27. Requires-Dist: setuptools
  28. Provides-Extra: docs
  29. Requires-Dist: Sphinx ; extra == 'docs'
  30. Requires-Dist: repoze.sphinx.autointerface ; extra == 'docs'
  31. Provides-Extra: test
  32. Requires-Dist: coverage (>=5.0.3) ; extra == 'test'
  33. Requires-Dist: zope.event ; extra == 'test'
  34. Requires-Dist: zope.testing ; extra == 'test'
  35. Provides-Extra: testing
  36. Requires-Dist: coverage (>=5.0.3) ; extra == 'testing'
  37. Requires-Dist: zope.event ; extra == 'testing'
  38. Requires-Dist: zope.testing ; extra == 'testing'
  39. ====================
  40. ``zope.interface``
  41. ====================
  42. .. image:: https://img.shields.io/pypi/v/zope.interface.svg
  43. :target: https://pypi.python.org/pypi/zope.interface/
  44. :alt: Latest Version
  45. .. image:: https://img.shields.io/pypi/pyversions/zope.interface.svg
  46. :target: https://pypi.org/project/zope.interface/
  47. :alt: Supported Python versions
  48. .. image:: https://github.com/zopefoundation/zope.interface/actions/workflows/tests.yml/badge.svg
  49. :target: https://github.com/zopefoundation/zope.interface/actions/workflows/tests.yml
  50. .. image:: https://readthedocs.org/projects/zopeinterface/badge/?version=latest
  51. :target: https://zopeinterface.readthedocs.io/en/latest/
  52. :alt: Documentation Status
  53. This package is intended to be independently reusable in any Python
  54. project. It is maintained by the `Zope Toolkit project
  55. <https://zopetoolkit.readthedocs.io/>`_.
  56. This package provides an implementation of "object interfaces" for Python.
  57. Interfaces are a mechanism for labeling objects as conforming to a given
  58. API or contract. So, this package can be considered as implementation of
  59. the `Design By Contract`_ methodology support in Python.
  60. .. _Design By Contract: http://en.wikipedia.org/wiki/Design_by_contract
  61. For detailed documentation, please see https://zopeinterface.readthedocs.io/en/latest/
  62. =========
  63. Changes
  64. =========
  65. 6.0 (2023-03-17)
  66. ================
  67. - Build Linux binary wheels for Python 3.11.
  68. - Drop support for Python 2.7, 3.5, 3.6.
  69. - Fix test deprecation warning on Python 3.11.
  70. - Add preliminary support for Python 3.12 as of 3.12a5.
  71. - Drop:
  72. + `zope.interface.implements`
  73. + `zope.interface.implementsOnly`
  74. + `zope.interface.classProvides`
  75. 5.5.2 (2022-11-17)
  76. ==================
  77. - Add support for building arm64 wheels on macOS.
  78. 5.5.1 (2022-11-03)
  79. ==================
  80. - Add support for final Python 3.11 release.
  81. 5.5.0 (2022-10-10)
  82. ==================
  83. - Add support for Python 3.10 and 3.11 (as of 3.11.0rc2).
  84. - Add missing Trove classifier showing support for Python 3.9.
  85. - Add some more entries to ``zope.interface.interfaces.__all__``.
  86. - Disable unsafe math optimizations in C code. See `pull request 262
  87. <https://github.com/zopefoundation/zope.interface/pull/262>`_.
  88. 5.4.0 (2021-04-15)
  89. ==================
  90. - Make the C implementation of the ``__providedBy__`` descriptor stop
  91. ignoring all errors raised when accessing the instance's
  92. ``__provides__``. Now it behaves like the Python version and only
  93. catches ``AttributeError``. The previous behaviour could lead to
  94. crashing the interpreter in cases of recursion and errors. See
  95. `issue 239 <https://github.com/zopefoundation/zope.interface/issues>`_.
  96. - Update the ``repr()`` and ``str()`` of various objects to be shorter
  97. and more informative. In many cases, the ``repr()`` is now something
  98. that can be evaluated to produce an equal object. For example, what
  99. was previously printed as ``<implementedBy builtins.list>`` is now
  100. shown as ``classImplements(list, IMutableSequence, IIterable)``. See
  101. `issue 236 <https://github.com/zopefoundation/zope.interface/issues/236>`_.
  102. - Make ``Declaration.__add__`` (as in ``implementedBy(Cls) +
  103. ISomething``) try harder to preserve a consistent resolution order
  104. when the two arguments share overlapping pieces of the interface
  105. inheritance hierarchy. Previously, the right hand side was always
  106. put at the end of the resolution order, which could easily produce
  107. invalid orders. See `issue 193
  108. <https://github.com/zopefoundation/zope.interface/issues/193>`_.
  109. 5.3.0 (2020-03-21)
  110. ==================
  111. - No changes from 5.3.0a1
  112. 5.3.0a1 (2021-03-18)
  113. ====================
  114. - Improve the repr of ``zope.interface.Provides`` to remove ambiguity
  115. about what is being provided. This is especially helpful diagnosing
  116. IRO issues.
  117. - Allow subclasses of ``BaseAdapterRegistry`` (including
  118. ``AdapterRegistry`` and ``VerifyingAdapterRegistry``) to have
  119. control over the data structures. This allows persistent
  120. implementations such as those based on ZODB to choose more scalable
  121. options (e.g., BTrees instead of dicts). See `issue 224
  122. <https://github.com/zopefoundation/zope.interface/issues/224>`_.
  123. - Fix a reference counting issue in ``BaseAdapterRegistry`` that could
  124. lead to references to interfaces being kept around even when all
  125. utilities/adapters/subscribers providing that interface have been
  126. removed. This is mostly an issue for persistent implementations.
  127. Note that this only corrects the issue moving forward, it does not
  128. solve any already corrupted reference counts. See `issue 227
  129. <https://github.com/zopefoundation/zope.interface/issues/227>`_.
  130. - Add the method ``BaseAdapterRegistry.rebuild()``. This can be used
  131. to fix the reference counting issue mentioned above, as well as to
  132. update the data structures when custom data types have changed.
  133. - Add the interface method ``IAdapterRegistry.subscribed()`` and
  134. implementation ``BaseAdapterRegistry.subscribed()`` for querying
  135. directly registered subscribers. See `issue 230
  136. <https://github.com/zopefoundation/zope.interface/issues/230>`_.
  137. - Add the maintenance method
  138. ``Components.rebuildUtilityRegistryFromLocalCache()``. Most users
  139. will not need this, but it can be useful if the ``Components.utilities``
  140. registry is suspected to be out of sync with the ``Components``
  141. object itself (this might happen to persistent ``Components``
  142. implementations in the face of bugs).
  143. - Fix the ``Provides`` and ``ClassProvides`` descriptors to stop
  144. allowing redundant interfaces (those already implemented by the
  145. underlying class or meta class) to produce an inconsistent
  146. resolution order. This is similar to the change in ``@implementer``
  147. in 5.1.0, and resolves inconsistent resolution orders with
  148. ``zope.proxy`` and ``zope.location``. See `issue 207
  149. <https://github.com/zopefoundation/zope.interface/issues/207>`_.
  150. 5.2.0 (2020-11-05)
  151. ==================
  152. - Add documentation section ``Persistency and Equality``
  153. (`#218 <https://github.com/zopefoundation/zope.interface/issues/218>`_).
  154. - Create arm64 wheels.
  155. - Add support for Python 3.9.
  156. 5.1.2 (2020-10-01)
  157. ==================
  158. - Make sure to call each invariant only once when validating invariants.
  159. Previously, invariants could be called multiple times because when an
  160. invariant is defined in an interface, it's found by in all interfaces
  161. inheriting from that interface. See `pull request 215
  162. <https://github.com/zopefoundation/zope.interface/pull/215/>`_.
  163. 5.1.1 (2020-09-30)
  164. ==================
  165. - Fix the method definitions of ``IAdapterRegistry.subscribe``,
  166. ``subscriptions`` and ``subscribers``. Previously, they all were
  167. defined to accept a ``name`` keyword argument, but subscribers have
  168. no names and the implementation of that interface did not accept
  169. that argument. See `issue 208
  170. <https://github.com/zopefoundation/zope.interface/issues/208>`_.
  171. - Fix a potential reference leak in the C optimizations. Previously,
  172. applications that dynamically created unique ``Specification``
  173. objects (e.g., used ``@implementer`` on dynamic classes) could
  174. notice a growth of small objects over time leading to increased
  175. garbage collection times. See `issue 216
  176. <https://github.com/zopefoundation/zope.interface/issues/216>`_.
  177. .. caution::
  178. This leak could prevent interfaces used as the bases of
  179. other interfaces from being garbage collected. Those interfaces
  180. will now be collected.
  181. One way in which this would manifest was that ``weakref.ref``
  182. objects (and things built upon them, like
  183. ``Weak[Key|Value]Dictionary``) would continue to have access to
  184. the original object even if there were no other visible
  185. references to Python and the original object *should* have been
  186. collected. This could be especially problematic for the
  187. ``WeakKeyDictionary`` when combined with dynamic or local
  188. (created in the scope of a function) interfaces, since interfaces
  189. are hashed based just on their name and module name. See the
  190. linked issue for an example of a resulting ``KeyError``.
  191. Note that such potential errors are not new, they are just once
  192. again a possibility.
  193. 5.1.0 (2020-04-08)
  194. ==================
  195. - Make ``@implementer(*iface)`` and ``classImplements(cls, *iface)``
  196. ignore redundant interfaces. If the class already implements an
  197. interface through inheritance, it is no longer redeclared
  198. specifically for *cls*. This solves many instances of inconsistent
  199. resolution orders, while still allowing the interface to be declared
  200. for readability and maintenance purposes. See `issue 199
  201. <https://github.com/zopefoundation/zope.interface/issues/199>`_.
  202. - Remove all bare ``except:`` statements. Previously, when accessing
  203. special attributes such as ``__provides__``, ``__providedBy__``,
  204. ``__class__`` and ``__conform__``, this package wrapped such access
  205. in a bare ``except:`` statement, meaning that many errors could pass
  206. silently; typically this would result in a fallback path being taken
  207. and sometimes (like with ``providedBy()``) the result would be
  208. non-sensical. This is especially true when those attributes are
  209. implemented with descriptors. Now, only ``AttributeError`` is
  210. caught. This makes errors more obvious.
  211. Obviously, this means that some exceptions will be propagated
  212. differently than before. In particular, ``RuntimeError`` raised by
  213. Acquisition in the case of circular containment will now be
  214. propagated. Previously, when adapting such a broken object, a
  215. ``TypeError`` would be the common result, but now it will be a more
  216. informative ``RuntimeError``.
  217. In addition, ZODB errors like ``POSKeyError`` could now be
  218. propagated where previously they would ignored by this package.
  219. See `issue 200 <https://github.com/zopefoundation/zope.interface/issues/200>`_.
  220. - Require that the second argument (*bases*) to ``InterfaceClass`` is
  221. a tuple. This only matters when directly using ``InterfaceClass`` to
  222. create new interfaces dynamically. Previously, an individual
  223. interface was allowed, but did not work correctly. Now it is
  224. consistent with ``type`` and requires a tuple.
  225. - Let interfaces define custom ``__adapt__`` methods. This implements
  226. the other side of the :pep:`246` adaptation protocol: objects being
  227. adapted could already implement ``__conform__`` if they know about
  228. the interface, and now interfaces can implement ``__adapt__`` if
  229. they know about particular objects. There is no performance penalty
  230. for interfaces that do not supply custom ``__adapt__`` methods.
  231. This includes the ability to add new methods, or override existing
  232. interface methods using the new ``@interfacemethod`` decorator.
  233. See `issue 3 <https://github.com/zopefoundation/zope.interface/issues/3>`_.
  234. - Make the internal singleton object returned by APIs like
  235. ``implementedBy`` and ``directlyProvidedBy`` for objects that
  236. implement or provide no interfaces more immutable. Previously an
  237. internal cache could be mutated. See `issue 204
  238. <https://github.com/zopefoundation/zope.interface/issues/204>`_.
  239. 5.0.2 (2020-03-30)
  240. ==================
  241. - Ensure that objects that implement no interfaces (such as direct
  242. subclasses of ``object``) still include ``Interface`` itself in
  243. their ``__iro___`` and ``__sro___``. This fixes adapter registry
  244. lookups for such objects when the adapter is registered for
  245. ``Interface``. See `issue 197
  246. <https://github.com/zopefoundation/zope.interface/issues/197>`_.
  247. 5.0.1 (2020-03-21)
  248. ==================
  249. - Ensure the resolution order for ``InterfaceClass`` is consistent.
  250. See `issue 192 <https://github.com/zopefoundation/zope.interface/issues/192>`_.
  251. - Ensure the resolution order for ``collections.OrderedDict`` is
  252. consistent on CPython 2. (It was already consistent on Python 3 and PyPy).
  253. - Fix the handling of the ``ZOPE_INTERFACE_STRICT_IRO`` environment
  254. variable. Previously, ``ZOPE_INTERFACE_STRICT_RO`` was read, in
  255. contrast with the documentation. See `issue 194
  256. <https://github.com/zopefoundation/zope.interface/issues/194>`_.
  257. 5.0.0 (2020-03-19)
  258. ==================
  259. - Make an internal singleton object returned by APIs like
  260. ``implementedBy`` and ``directlyProvidedBy`` immutable. Previously,
  261. it was fully mutable and allowed changing its ``__bases___``. That
  262. could potentially lead to wrong results in pathological corner
  263. cases. See `issue 158
  264. <https://github.com/zopefoundation/zope.interface/issues/158>`_.
  265. - Support the ``PURE_PYTHON`` environment variable at runtime instead
  266. of just at wheel build time. A value of 0 forces the C extensions to
  267. be used (even on PyPy) failing if they aren't present. Any other
  268. value forces the Python implementation to be used, ignoring the C
  269. extensions. See `PR 151 <https://github.com/zopefoundation/zope.interface/pull/151>`_.
  270. - Cache the result of ``__hash__`` method in ``InterfaceClass`` as a
  271. speed optimization. The method is called very often (i.e several
  272. hundred thousand times during Plone 5.2 startup). Because the hash value never
  273. changes it can be cached. This improves test performance from 0.614s
  274. down to 0.575s (1.07x faster). In a real world Plone case a reindex
  275. index came down from 402s to 320s (1.26x faster). See `PR 156
  276. <https://github.com/zopefoundation/zope.interface/pull/156>`_.
  277. - Change the C classes ``SpecificationBase`` and its subclass
  278. ``ClassProvidesBase`` to store implementation attributes in their structures
  279. instead of their instance dictionaries. This eliminates the use of
  280. an undocumented private C API function, and helps make some
  281. instances require less memory. See `PR 154 <https://github.com/zopefoundation/zope.interface/pull/154>`_.
  282. - Reduce memory usage in other ways based on observations of usage
  283. patterns in Zope (3) and Plone code bases.
  284. - Specifications with no dependents are common (more than 50%) so
  285. avoid allocating a ``WeakKeyDictionary`` unless we need it.
  286. - Likewise, tagged values are relatively rare, so don't allocate a
  287. dictionary to hold them until they are used.
  288. - Use ``__slots___`` or the C equivalent ``tp_members`` in more
  289. common places. Note that this removes the ability to set arbitrary
  290. instance variables on certain objects.
  291. See `PR 155 <https://github.com/zopefoundation/zope.interface/pull/155>`_.
  292. The changes in this release resulted in a 7% memory reduction after
  293. loading about 6,000 modules that define about 2,200 interfaces.
  294. .. caution::
  295. Details of many private attributes have changed, and external use
  296. of those private attributes may break. In particular, the
  297. lifetime and default value of ``_v_attrs`` has changed.
  298. - Remove support for hashing uninitialized interfaces. This could only
  299. be done by subclassing ``InterfaceClass``. This has generated a
  300. warning since it was first added in 2011 (3.6.5). Please call the
  301. ``InterfaceClass`` constructor or otherwise set the appropriate
  302. fields in your subclass before attempting to hash or sort it. See
  303. `issue 157 <https://github.com/zopefoundation/zope.interface/issues/157>`_.
  304. - Remove unneeded override of the ``__hash__`` method from
  305. ``zope.interface.declarations.Implements``. Watching a reindex index
  306. process in ZCatalog with on a Py-Spy after 10k samples the time for
  307. ``.adapter._lookup`` was reduced from 27.5s to 18.8s (~1.5x faster).
  308. Overall reindex index time shrunk from 369s to 293s (1.26x faster).
  309. See `PR 161
  310. <https://github.com/zopefoundation/zope.interface/pull/161>`_.
  311. - Make the Python implementation closer to the C implementation by
  312. ignoring all exceptions, not just ``AttributeError``, during (parts
  313. of) interface adaptation. See `issue 163
  314. <https://github.com/zopefoundation/zope.interface/issues/163>`_.
  315. - Micro-optimization in ``.adapter._lookup`` , ``.adapter._lookupAll``
  316. and ``.adapter._subscriptions``: By loading ``components.get`` into
  317. a local variable before entering the loop a bytcode "LOAD_FAST 0
  318. (components)" in the loop can be eliminated. In Plone, while running
  319. all tests, average speedup of the "owntime" of ``_lookup`` is ~5x.
  320. See `PR 167
  321. <https://github.com/zopefoundation/zope.interface/pull/167>`_.
  322. - Add ``__all__`` declarations to all modules. This helps tools that
  323. do auto-completion and documentation and results in less cluttered
  324. results. Wildcard ("*") are not recommended and may be affected. See
  325. `issue 153
  326. <https://github.com/zopefoundation/zope.interface/issues/153>`_.
  327. - Fix ``verifyClass`` and ``verifyObject`` for builtin types like
  328. ``dict`` that have methods taking an optional, unnamed argument with
  329. no default value like ``dict.pop``. On PyPy3, the verification is
  330. strict, but on PyPy2 (as on all versions of CPython) those methods
  331. cannot be verified and are ignored. See `issue 118
  332. <https://github.com/zopefoundation/zope.interface/issues/118>`_.
  333. - Update the common interfaces ``IEnumerableMapping``,
  334. ``IExtendedReadMapping``, ``IExtendedWriteMapping``,
  335. ``IReadSequence`` and ``IUniqueMemberWriteSequence`` to no longer
  336. require methods that were removed from Python 3 on Python 3, such as
  337. ``__setslice___``. Now, ``dict``, ``list`` and ``tuple`` properly
  338. verify as ``IFullMapping``, ``ISequence`` and ``IReadSequence,``
  339. respectively on all versions of Python.
  340. - Add human-readable ``__str___`` and ``__repr___`` to ``Attribute``
  341. and ``Method``. These contain the name of the defining interface
  342. and the attribute. For methods, it also includes the signature.
  343. - Change the error strings raised by ``verifyObject`` and
  344. ``verifyClass``. They now include more human-readable information
  345. and exclude extraneous lines and spaces. See `issue 170
  346. <https://github.com/zopefoundation/zope.interface/issues/170>`_.
  347. .. caution:: This will break consumers (such as doctests) that
  348. depended on the exact error messages.
  349. - Make ``verifyObject`` and ``verifyClass`` report all errors, if the
  350. candidate object has multiple detectable violations. Previously they
  351. reported only the first error. See `issue
  352. <https://github.com/zopefoundation/zope.interface/issues/171>`_.
  353. Like the above, this will break consumers depending on the exact
  354. output of error messages if more than one error is present.
  355. - Add ``zope.interface.common.collections``,
  356. ``zope.interface.common.numbers``, and ``zope.interface.common.io``.
  357. These modules define interfaces based on the ABCs defined in the
  358. standard library ``collections.abc``, ``numbers`` and ``io``
  359. modules, respectively. Importing these modules will make the
  360. standard library concrete classes that are registered with those
  361. ABCs declare the appropriate interface. See `issue 138
  362. <https://github.com/zopefoundation/zope.interface/issues/138>`_.
  363. - Add ``zope.interface.common.builtins``. This module defines
  364. interfaces of common builtin types, such as ``ITextString`` and
  365. ``IByteString``, ``IDict``, etc. These interfaces extend the
  366. appropriate interfaces from ``collections`` and ``numbers``, and the
  367. standard library classes implement them after importing this module.
  368. This is intended as a replacement for third-party packages like
  369. `dolmen.builtins <https://pypi.org/project/dolmen.builtins/>`_.
  370. See `issue 138 <https://github.com/zopefoundation/zope.interface/issues/138>`_.
  371. - Make ``providedBy()`` and ``implementedBy()`` respect ``super``
  372. objects. For instance, if class ``Derived`` implements ``IDerived``
  373. and extends ``Base`` which in turn implements ``IBase``, then
  374. ``providedBy(super(Derived, derived))`` will return ``[IBase]``.
  375. Previously it would have returned ``[IDerived]`` (in general, it
  376. would previously have returned whatever would have been returned
  377. without ``super``).
  378. Along with this change, adapter registries will unpack ``super``
  379. objects into their ``__self___`` before passing it to the factory.
  380. Together, this means that ``component.getAdapter(super(Derived,
  381. self), ITarget)`` is now meaningful.
  382. See `issue 11 <https://github.com/zopefoundation/zope.interface/issues/11>`_.
  383. - Fix a potential interpreter crash in the low-level adapter
  384. registry lookup functions. See issue 11.
  385. - Adopt Python's standard `C3 resolution order
  386. <https://www.python.org/download/releases/2.3/mro/>`_ to compute the
  387. ``__iro__`` and ``__sro__`` of interfaces, with tweaks to support
  388. additional cases that are common in interfaces but disallowed for
  389. Python classes. Previously, an ad-hoc ordering that made no
  390. particular guarantees was used.
  391. This has many beneficial properties, including the fact that base
  392. interface and base classes tend to appear near the end of the
  393. resolution order instead of the beginning. The resolution order in
  394. general should be more predictable and consistent.
  395. .. caution::
  396. In some cases, especially with complex interface inheritance
  397. trees or when manually providing or implementing interfaces, the
  398. resulting IRO may be quite different. This may affect adapter
  399. lookup.
  400. The C3 order enforces some constraints in order to be able to
  401. guarantee a sensible ordering. Older versions of zope.interface did
  402. not impose similar constraints, so it was possible to create
  403. interfaces and declarations that are inconsistent with the C3
  404. constraints. In that event, zope.interface will still produce a
  405. resolution order equal to the old order, but it won't be guaranteed
  406. to be fully C3 compliant. In the future, strict enforcement of C3
  407. order may be the default.
  408. A set of environment variables and module constants allows
  409. controlling several aspects of this new behaviour. It is possible to
  410. request warnings about inconsistent resolution orders encountered,
  411. and even to forbid them. Differences between the C3 resolution order
  412. and the previous order can be logged, and, in extreme cases, the
  413. previous order can still be used (this ability will be removed in
  414. the future). For details, see the documentation for
  415. ``zope.interface.ro``.
  416. - Make inherited tagged values in interfaces respect the resolution
  417. order (``__iro__``), as method and attribute lookup does. Previously
  418. tagged values could give inconsistent results. See `issue 190
  419. <https://github.com/zopefoundation/zope.interface/issues/190>`_.
  420. - Add ``getDirectTaggedValue`` (and related methods) to interfaces to
  421. allow accessing tagged values irrespective of inheritance. See
  422. `issue 190
  423. <https://github.com/zopefoundation/zope.interface/issues/190>`_.
  424. - Ensure that ``Interface`` is always the last item in the ``__iro__``
  425. and ``__sro__``. This is usually the case, but if classes that do
  426. not implement any interfaces are part of a class inheritance
  427. hierarchy, ``Interface`` could be assigned too high a priority.
  428. See `issue 8 <https://github.com/zopefoundation/zope.interface/issues/8>`_.
  429. - Implement sorting, equality, and hashing in C for ``Interface``
  430. objects. In micro benchmarks, this makes those operations 40% to 80%
  431. faster. This translates to a 20% speed up in querying adapters.
  432. Note that this changes certain implementation details. In
  433. particular, ``InterfaceClass`` now has a non-default metaclass, and
  434. it is enforced that ``__module__`` in instances of
  435. ``InterfaceClass`` is read-only.
  436. See `PR 183 <https://github.com/zopefoundation/zope.interface/pull/183>`_.
  437. 4.7.2 (2020-03-10)
  438. ==================
  439. - Remove deprecated use of setuptools features. See `issue 30
  440. <https://github.com/zopefoundation/zope.interface/issues/30>`_.
  441. 4.7.1 (2019-11-11)
  442. ==================
  443. - Use Python 3 syntax in the documentation. See `issue 119
  444. <https://github.com/zopefoundation/zope.interface/issues/119>`_.
  445. 4.7.0 (2019-11-11)
  446. ==================
  447. - Drop support for Python 3.4.
  448. - Change ``queryTaggedValue``, ``getTaggedValue``,
  449. ``getTaggedValueTags`` in interfaces. They now include inherited
  450. values by following ``__bases__``. See `PR 144
  451. <https://github.com/zopefoundation/zope.interface/pull/144>`_.
  452. .. caution:: This may be a breaking change.
  453. - Add support for Python 3.8.
  454. 4.6.0 (2018-10-23)
  455. ==================
  456. - Add support for Python 3.7
  457. - Fix ``verifyObject`` for class objects with staticmethods on
  458. Python 3. See `issue 126
  459. <https://github.com/zopefoundation/zope.interface/issues/126>`_.
  460. 4.5.0 (2018-04-19)
  461. ==================
  462. - Drop support for 3.3, avoid accidental dependence breakage via setup.py.
  463. See `PR 110 <https://github.com/zopefoundation/zope.interface/pull/110>`_.
  464. - Allow registering and unregistering instance methods as listeners.
  465. See `issue 12 <https://github.com/zopefoundation/zope.interface/issues/12>`_
  466. and `PR 102 <https://github.com/zopefoundation/zope.interface/pull/102>`_.
  467. - Synchronize and simplify zope/__init__.py. See `issue 114
  468. <https://github.com/zopefoundation/zope.interface/issues/114>`_
  469. 4.4.3 (2017-09-22)
  470. ==================
  471. - Avoid exceptions when the ``__annotations__`` attribute is added to
  472. interface definitions with Python 3.x type hints. See `issue 98
  473. <https://github.com/zopefoundation/zope.interface/issues/98>`_.
  474. - Fix the possibility of a rare crash in the C extension when
  475. deallocating items. See `issue 100
  476. <https://github.com/zopefoundation/zope.interface/issues/100>`_.
  477. 4.4.2 (2017-06-14)
  478. ==================
  479. - Fix a regression storing
  480. ``zope.component.persistentregistry.PersistentRegistry`` instances.
  481. See `issue 85 <https://github.com/zopefoundation/zope.interface/issues/85>`_.
  482. - Fix a regression that could lead to the utility registration cache
  483. of ``Components`` getting out of sync. See `issue 93
  484. <https://github.com/zopefoundation/zope.interface/issues/93>`_.
  485. 4.4.1 (2017-05-13)
  486. ==================
  487. - Simplify the caching of utility-registration data. In addition to
  488. simplification, avoids spurious test failures when checking for
  489. leaks in tests with persistent registries. See `pull 84
  490. <https://github.com/zopefoundation/zope.interface/pull/84>`_.
  491. - Raise ``ValueError`` when non-text names are passed to adapter registry
  492. methods: prevents corruption of lookup caches.
  493. 4.4.0 (2017-04-21)
  494. ==================
  495. - Avoid a warning from the C compiler.
  496. (https://github.com/zopefoundation/zope.interface/issues/71)
  497. - Add support for Python 3.6.
  498. 4.3.3 (2016-12-13)
  499. ==================
  500. - Correct typos and ReST formatting errors in documentation.
  501. - Add API documentation for the adapter registry.
  502. - Ensure that the ``LICENSE.txt`` file is included in built wheels.
  503. - Fix C optimizations broken on Py3k. See the Python bug at:
  504. http://bugs.python.org/issue15657
  505. (https://github.com/zopefoundation/zope.interface/issues/60)
  506. 4.3.2 (2016-09-05)
  507. ==================
  508. - Fix equality testing of ``implementedBy`` objects and proxies.
  509. (https://github.com/zopefoundation/zope.interface/issues/55)
  510. 4.3.1 (2016-08-31)
  511. ==================
  512. - Support Components subclasses that are not hashable.
  513. (https://github.com/zopefoundation/zope.interface/issues/53)
  514. 4.3.0 (2016-08-31)
  515. ==================
  516. - Add the ability to sort the objects returned by ``implementedBy``.
  517. This is compatible with the way interface classes sort so they can
  518. be used together in ordered containers like BTrees.
  519. (https://github.com/zopefoundation/zope.interface/issues/42)
  520. - Make ``setuptools`` a hard dependency of ``setup.py``.
  521. (https://github.com/zopefoundation/zope.interface/issues/13)
  522. - Change a linear algorithm (O(n)) in ``Components.registerUtility`` and
  523. ``Components.unregisterUtility`` into a dictionary lookup (O(1)) for
  524. hashable components. This substantially improves the time taken to
  525. manipulate utilities in large registries at the cost of some
  526. additional memory usage. (https://github.com/zopefoundation/zope.interface/issues/46)
  527. 4.2.0 (2016-06-10)
  528. ==================
  529. - Add support for Python 3.5
  530. - Drop support for Python 2.6 and 3.2.
  531. 4.1.3 (2015-10-05)
  532. ==================
  533. - Fix installation without a C compiler on Python 3.5
  534. (https://github.com/zopefoundation/zope.interface/issues/24).
  535. 4.1.2 (2014-12-27)
  536. ==================
  537. - Add support for PyPy3.
  538. - Remove unittest assertions deprecated in Python3.x.
  539. - Add ``zope.interface.document.asReStructuredText``, which formats the
  540. generated text for an interface using ReST double-backtick markers.
  541. 4.1.1 (2014-03-19)
  542. ==================
  543. - Add support for Python 3.4.
  544. 4.1.0 (2014-02-05)
  545. ==================
  546. - Update ``boostrap.py`` to version 2.2.
  547. - Add ``@named(name)`` declaration, that specifies the component name, so it
  548. does not have to be passed in during registration.
  549. 4.0.5 (2013-02-28)
  550. ==================
  551. - Fix a bug where a decorated method caused false positive failures on
  552. ``verifyClass()``.
  553. 4.0.4 (2013-02-21)
  554. ==================
  555. - Fix a bug that was revealed by porting zope.traversing. During a loop, the
  556. loop body modified a weakref dict causing a ``RuntimeError`` error.
  557. 4.0.3 (2012-12-31)
  558. ==================
  559. - Fleshed out PyPI Trove classifiers.
  560. 4.0.2 (2012-11-21)
  561. ==================
  562. - Add support for Python 3.3.
  563. - Restored ability to install the package in the absence of ``setuptools``.
  564. - LP #1055223: Fix test which depended on dictionary order and failed randomly
  565. in Python 3.3.
  566. 4.0.1 (2012-05-22)
  567. ==================
  568. - Drop explicit ``DeprecationWarnings`` for "class advice" APIS (these
  569. APIs are still deprecated under Python 2.x, and still raise an exception
  570. under Python 3.x, but no longer cause a warning to be emitted under
  571. Python 2.x).
  572. 4.0.0 (2012-05-16)
  573. ==================
  574. - Automated build of Sphinx HTML docs and running doctest snippets via tox.
  575. - Deprecate the "class advice" APIs from ``zope.interface.declarations``:
  576. ``implements``, ``implementsOnly``, and ``classProvides``. In their place,
  577. prefer the equivalent class decorators: ``@implementer``,
  578. ``@implementer_only``, and ``@provider``. Code which uses the deprecated
  579. APIs will not work as expected under Py3k.
  580. - Remove use of '2to3' and associated fixers when installing under Py3k.
  581. The code is now in a "compatible subset" which supports Python 2.6, 2.7,
  582. and 3.2, including PyPy 1.8 (the version compatible with the 2.7 language
  583. spec).
  584. - Drop explicit support for Python 2.4 / 2.5 / 3.1.
  585. - Add support for PyPy.
  586. - Add support for continuous integration using ``tox`` and ``jenkins``.
  587. - Add 'setup.py dev' alias (runs ``setup.py develop`` plus installs
  588. ``nose`` and ``coverage``).
  589. - Add 'setup.py docs' alias (installs ``Sphinx`` and dependencies).
  590. - Replace all unittest coverage previously accomplished via doctests with
  591. unittests. The doctests have been moved into a ``docs`` section, managed
  592. as a Sphinx collection.
  593. - LP #910987: Ensure that the semantics of the ``lookup`` method of
  594. ``zope.interface.adapter.LookupBase`` are the same in both the C and
  595. Python implementations.
  596. - LP #900906: Avoid exceptions due to tne new ``__qualname__`` attribute
  597. added in Python 3.3 (see PEP 3155 for rationale). Thanks to Antoine
  598. Pitrou for the patch.
  599. 3.8.0 (2011-09-22)
  600. ==================
  601. - New module ``zope.interface.registry``. This is code moved from
  602. ``zope.component.registry`` which implements a basic nonperistent component
  603. registry as ``zope.interface.registry.Components``. This class was moved
  604. from ``zope.component`` to make porting systems (such as Pyramid) that rely
  605. only on a basic component registry to Python 3 possible without needing to
  606. port the entirety of the ``zope.component`` package. Backwards
  607. compatibility import shims have been left behind in ``zope.component``, so
  608. this change will not break any existing code.
  609. - New ``tests_require`` dependency: ``zope.event`` to test events sent by
  610. Components implementation. The ``zope.interface`` package does not have a
  611. hard dependency on ``zope.event``, but if ``zope.event`` is importable, it
  612. will send component registration events when methods of an instance of
  613. ``zope.interface.registry.Components`` are called.
  614. - New interfaces added to support ``zope.interface.registry.Components``
  615. addition: ``ComponentLookupError``, ``Invalid``, ``IObjectEvent``,
  616. ``ObjectEvent``, ``IComponentLookup``, ``IRegistration``,
  617. ``IUtilityRegistration``, ``IAdapterRegistration``,
  618. ``ISubscriptionAdapterRegistration``, ``IHandlerRegistration``,
  619. ``IRegistrationEvent``, ``RegistrationEvent``, ``IRegistered``,
  620. ``Registered``, ``IUnregistered``, ``Unregistered``,
  621. ``IComponentRegistry``, and ``IComponents``.
  622. - No longer Python 2.4 compatible (tested under 2.5, 2.6, 2.7, and 3.2).
  623. 3.7.0 (2011-08-13)
  624. ==================
  625. - Move changes from 3.6.2 - 3.6.5 to a new 3.7.x release line.
  626. 3.6.7 (2011-08-20)
  627. ==================
  628. - Fix sporadic failures on x86-64 platforms in tests of rich comparisons
  629. of interfaces.
  630. 3.6.6 (2011-08-13)
  631. ==================
  632. - LP #570942: Now correctly compare interfaces from different modules but
  633. with the same names.
  634. N.B.: This is a less intrusive / destabilizing fix than the one applied in
  635. 3.6.3: we only fix the underlying cmp-alike function, rather than adding
  636. the other "rich comparison" functions.
  637. - Revert to software as released with 3.6.1 for "stable" 3.6 release branch.
  638. 3.6.5 (2011-08-11)
  639. ==================
  640. - LP #811792: work around buggy behavior in some subclasses of
  641. ``zope.interface.interface.InterfaceClass``, which invoke ``__hash__``
  642. before initializing ``__module__`` and ``__name__``. The workaround
  643. returns a fixed constant hash in such cases, and issues a ``UserWarning``.
  644. - LP #804832: Under PyPy, ``zope.interface`` should not build its C
  645. extension. Also, prevent attempting to build it under Jython.
  646. - Add a tox.ini for easier xplatform testing.
  647. - Fix testing deprecation warnings issued when tested under Py3K.
  648. 3.6.4 (2011-07-04)
  649. ==================
  650. - LP 804951: InterfaceClass instances were unhashable under Python 3.x.
  651. 3.6.3 (2011-05-26)
  652. ==================
  653. - LP #570942: Now correctly compare interfaces from different modules but
  654. with the same names.
  655. 3.6.2 (2011-05-17)
  656. ==================
  657. - Moved detailed documentation out-of-line from PyPI page, linking instead to
  658. http://docs.zope.org/zope.interface .
  659. - Fixes for small issues when running tests under Python 3.2 using
  660. ``zope.testrunner``.
  661. - LP # 675064: Specify return value type for C optimizations module init
  662. under Python 3: undeclared value caused warnings, and segfaults on some
  663. 64 bit architectures.
  664. - setup.py now raises RuntimeError if you don't have Distutils installed when
  665. running under Python 3.
  666. 3.6.1 (2010-05-03)
  667. ==================
  668. - A non-ASCII character in the changelog made 3.6.0 uninstallable on
  669. Python 3 systems with another default encoding than UTF-8.
  670. - Fix compiler warnings under GCC 4.3.3.
  671. 3.6.0 (2010-04-29)
  672. ==================
  673. - LP #185974: Clear the cache used by ``Specificaton.get`` inside
  674. ``Specification.changed``. Thanks to Jacob Holm for the patch.
  675. - Add support for Python 3.1. Contributors:
  676. Lennart Regebro
  677. Martin v Loewis
  678. Thomas Lotze
  679. Wolfgang Schnerring
  680. The 3.1 support is completely backwards compatible. However, the implements
  681. syntax used under Python 2.X does not work under 3.X, since it depends on
  682. how metaclasses are implemented and this has changed. Instead it now supports
  683. a decorator syntax (also under Python 2.X)::
  684. class Foo:
  685. implements(IFoo)
  686. ...
  687. can now also be written::
  688. @implementer(IFoo):
  689. class Foo:
  690. ...
  691. There are 2to3 fixers available to do this change automatically in the
  692. zope.fixers package.
  693. - Python 2.3 is no longer supported.
  694. 3.5.4 (2009-12-23)
  695. ==================
  696. - Use the standard Python doctest module instead of zope.testing.doctest, which
  697. has been deprecated.
  698. 3.5.3 (2009-12-08)
  699. ==================
  700. - Fix an edge case: make providedBy() work when a class has '__provides__' in
  701. its __slots__ (see http://thread.gmane.org/gmane.comp.web.zope.devel/22490)
  702. 3.5.2 (2009-07-01)
  703. ==================
  704. - BaseAdapterRegistry.unregister, unsubscribe: Remove empty portions of
  705. the data structures when something is removed. This avoids leaving
  706. references to global objects (interfaces) that may be slated for
  707. removal from the calling application.
  708. 3.5.1 (2009-03-18)
  709. ==================
  710. - verifyObject: use getattr instead of hasattr to test for object attributes
  711. in order to let exceptions other than AttributeError raised by properties
  712. propagate to the caller
  713. - Add Sphinx-based documentation building to the package buildout
  714. configuration. Use the ``bin/docs`` command after buildout.
  715. - Improve package description a bit. Unify changelog entries formatting.
  716. - Change package's mailing list address to zope-dev at zope.org as
  717. zope3-dev at zope.org is now retired.
  718. 3.5.0 (2008-10-26)
  719. ==================
  720. - Fix declaration of _zope_interface_coptimizations, it's not a top level
  721. package.
  722. - Add a DocTestSuite for odd.py module, so their tests are run.
  723. - Allow to bootstrap on Jython.
  724. - Fix https://bugs.launchpad.net/zope3/3.3/+bug/98388: ISpecification
  725. was missing a declaration for __iro__.
  726. - Add optional code optimizations support, which allows the building
  727. of C code optimizations to fail (Jython).
  728. - Replace `_flatten` with a non-recursive implementation, effectively making
  729. it 3x faster.
  730. 3.4.1 (2007-10-02)
  731. ==================
  732. - Fix a setup bug that prevented installation from source on systems
  733. without setuptools.
  734. 3.4.0 (2007-07-19)
  735. ==================
  736. - Final release for 3.4.0.
  737. 3.4.0b3 (2007-05-22)
  738. ====================
  739. - When checking whether an object is already registered, use identity
  740. comparison, to allow adding registering with picky custom comparison methods.
  741. 3.3.0.1 (2007-01-03)
  742. ====================
  743. - Made a reference to OverflowWarning, which disappeared in Python
  744. 2.5, conditional.
  745. 3.3.0 (2007/01/03)
  746. ==================
  747. New Features
  748. ------------
  749. - Refactor the adapter-lookup algorithim to make it much simpler and faster.
  750. Also, implement more of the adapter-lookup logic in C, making
  751. debugging of application code easier, since there is less
  752. infrastructre code to step through.
  753. - Treat objects without interface declarations as if they
  754. declared that they provide ``zope.interface.Interface``.
  755. - Add a number of richer new adapter-registration interfaces
  756. that provide greater control and introspection.
  757. - Add a new interface decorator to zope.interface that allows the
  758. setting of tagged values on an interface at definition time (see
  759. zope.interface.taggedValue).
  760. Bug Fixes
  761. ---------
  762. - A bug in multi-adapter lookup sometimes caused incorrect adapters to
  763. be returned.
  764. 3.2.0.2 (2006-04-15)
  765. ====================
  766. - Fix packaging bug: 'package_dir' must be a *relative* path.
  767. 3.2.0.1 (2006-04-14)
  768. ====================
  769. - Packaging change: suppress inclusion of 'setup.cfg' in 'sdist' builds.
  770. 3.2.0 (2006-01-05)
  771. ==================
  772. - Corresponds to the version of the zope.interface package shipped as part of
  773. the Zope 3.2.0 release.
  774. 3.1.0 (2005-10-03)
  775. ==================
  776. - Corresponds to the version of the zope.interface package shipped as part of
  777. the Zope 3.1.0 release.
  778. - Made attribute resolution order consistent with component lookup order,
  779. i.e. new-style class MRO semantics.
  780. - Deprecate 'isImplementedBy' and 'isImplementedByInstancesOf' APIs in
  781. favor of 'implementedBy' and 'providedBy'.
  782. 3.0.1 (2005-07-27)
  783. ==================
  784. - Corresponds to the version of the zope.interface package shipped as part of
  785. the Zope X3.0.1 release.
  786. - Fix a bug reported by James Knight, which caused adapter registries
  787. to fail occasionally to reflect declaration changes.
  788. 3.0.0 (2004-11-07)
  789. ==================
  790. - Corresponds to the version of the zope.interface package shipped as part of
  791. the Zope X3.0.0 release.