| |
Fixes and changes since PyProtocols 0.9.3 |
| |
|
| |
- There is a new 'protocols.advice.add_assignment_advisor' function that |
| |
allows you to implement PEP 318-like decorators in Python 2.2 and 2.3. |
| |
There is also a convenience function, 'as', that lets you use PEP 318-style |
| |
decorators directly. (DOCS NEEDED) |
| |
|
| |
- 'StickyAdapter' is now a one-argument adapter factory; as a result, the |
| |
'protocol' attribute is now completely gone, and you *must* use the |
| |
'attachForProtocols' attribute in order to get any actual "stickiness". |
| |
See the reference manual for details on the 'attachForProtocols' attribute. |
| |
|
| |
- 'adapt()' no longer supports the 'factory' argument that was deprecated in |
| |
0.9.3. |
| |
|
| |
- Using two-argument adapter factories now produces a DeprecationWarning; |
| |
please update your code, since support for them will be gone entirely in |
| |
version 1.1. |
| |
|
| |
|
| Fixes and changes since PyProtocols 0.9.2 |
Fixes and changes since PyProtocols 0.9.2 |
| |
|
| - The 'factory' parameter to 'adapt()' was REMOVED. An informal survey of |
- 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.) |
| |
|
| |
- The 'factory' parameter to 'adapt()' is DEPRECATED. An informal survey of |
| PyProtocols' users indicated that nobody was using it to any significant |
PyProtocols' users indicated that nobody was using it to any significant |
| degree, and its removal was unopposed. This feature was an extension to |
degree, and its removal was unopposed. This feature was an extension to |
| PEP 246, so this brings PyProtocols into closer conformance with the PEP. |
PEP 246, so this brings PyProtocols into closer conformance with the PEP. |
| |
If you are currently using it, you will receive a 'DeprecationWarning', and |
| |
in PyProtocols 1.0 your code will break. |
| |
|
| |
- Fixed 'protocols.sequenceOf()' being unable to directly imply a non-sequence |
| |
protocol. |
| |
|
| - Raise 'AdaptationFailure' instead of 'NotImplementedError' when adaptation |
- Raise 'AdaptationFailure' instead of 'NotImplementedError' when adaptation |
| is unsuccessful. 'AdaptationFailure' is a subclass of both 'TypeError' and |
is unsuccessful. 'AdaptationFailure' is a subclass of both 'TypeError' and |
| interface may contain implementation code, and can be subclassed to create |
interface may contain implementation code, and can be subclassed to create |
| concrete implementations. In previous versions, you could use 'Interface' |
concrete implementations. In previous versions, you could use 'Interface' |
| as such a base class, but now calling an 'Interface' object performs |
as such a base class, but now calling an 'Interface' object performs |
| adaptation, rather than instantiation. |
adaptation rather than instantiation, unless the subclass redefines |
| |
'__init__'. |
| |
|
| - 'Protocol' instances (except for 'AbstractBase' subclasses) are now callable |
- 'Protocol' instances (except for 'AbstractBase' subclasses) are now callable |
| with a signature similar to 'adapt()'. E.g. 'ISomething(foo,*args)' is |
with a signature similar to 'adapt()'. E.g. 'ISomething(foo,*args)' is |
Diff of /PyProtocols/CHANGES.txt
Parent Directory
| 
Revision Log