[Subversion] / PyProtocols / CHANGES.txt |
No default branch
Bookmark a link to HEAD:
(view)
(download)
Get rid of "class" vs. "class-exec" distinction for 'getFrameInfo()'; it is more a source of errors than anything else.
Added support to make 'protocols.advise()' operate correctly in a doctest or other 'exec' scenario. 'protocols.advice.getFrameInfo()' now returns a 'kind' of '"class-exec"' for that situation.
Implement some of the changes that were planned for 1.0; cleanup TODO, CHANGES, UPGRADING, and manual for current '1.0a0' CVS version status.
Backport useful fixes from the 0.9.x branch to the trunk
Adapter factories are now only called with one argument: the object to adapt. For backward compatibility, any adapter factories that require more than one argument are wrapped in a converter. It's highly recommended that you transition to one-argument adapters as soon as practical, since using two-argument adapters will cause deprecation warnings in PyProtocols version 1.0 (and causes PendingDeprecationWarnings in 0.9.3). This change was made for symmetry with Zope and Twisted adapters, as well as Pythonic adapter factories like 'int' et al. (Note that as a result of this change, 'Adapter' objects no longer have a 'protocol' attribute, and 'StickyAdapter' objects will also lose their 'protocol' attribute in 1.0.) Also, I restored the previously-removed 'factory' argument to 'adapt()', but it generates a DeprecationWarning if you use it. Thus, programs written for PyProtocols 0.9.2 that use this argument will keep working until version 1.0, making the 'protocol' attribute the only bit that's not 100% backward compatible.
Fixed 'protocols.sequenceOf()' being unable to directly imply a non-sequence protocol.
Removed 'factory' parameter from the 'adapt()' function, bringing us more in line with PEP 246, and preparing for the removal of the second parameter of adapter factories.
Added 'protocols.AdaptationFailure' exception. Added 'TODO.txt'.
Implement Twisted-style 'IFoo(ob)' as shorthand for 'adapt(ob,IFoo)'. As a result, there's now an 'AbstractBase' you can subclass instead of 'Interface', if you need the old behavior. See CHANGES.txt and the updated docs for the full lowdown. (Note that *all* 'Protocol' subclasses other than 'AbstractBase' now do this, not just 'Interface'.) Note that this change will break 'peak.util.fmtparse' (at least), so I'm going to go fix that next.
Sync w/setuptools. Add '--without-speedups' option. Add 'adapter_hooks' support for latest Zope X3 CVS. Update version info for 0.9.3 release.
Cosmetic doc fix.
Bug fix: Declaring an adapter from an instance to a protocol that was part of a circular implication path resulted in infinite recursion. Correcting the problem required a change in the return signature of the 'declareProvides()' method in the 'IOpenProvider' interface. Please see the docstring or the updated reference manual for details. Thanks to Bob Ippolito for discovering the problem and bringing it to my attention.
Bug fix: defining an adapter from one protocol to another, when that adapter does not shorten the adaptation path, would produce a spurious 'KeyError'.
Prep for 0.9.2 release.
Update docs for 0.9.1 release. Still need to review latest Zope X3 and Twisted releases to ensure we're still compatible. Other than that, this looks pretty ready to go.
Update PyProtocols CHANGES for test suite bugfixes.
Started documenting features for PyProtocols 1.0.
Added 'sequenceOf()', allowing you to easily create a protocol that represents a sequence of some base protocol, and automatically adapt basic sequences (e.g. lists and tuples) to a "sequence of" the base protocol, as long as all members of the input sequence can be adapted to the base protocol. By default, only lists and tuples are considered to support 'IBasicSequence'.
protocolForType(), protocolForURI(), and 'advise(equivalentProtocols=[])'. Also, added 'CHANGES.txt', which contains a full explanation of the above, and catches up notes on all the other fixes and enhancements since PyProtocols 0.9 was released.
cvs-admin@eby-sarna.com Powered by ViewCVS 1.0-dev |
ViewCVS and CVS Help |