[Subversion] / PyProtocols / CHANGES.txt  

Diff of /PyProtocols/CHANGES.txt

Parent Directory | Revision Log

version 126, Sat Jun 19 21:48:15 2004 UTC version 132, Tue Jul 6 01:51:19 2004 UTC
Line 1 
Line 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
Line 15 
Line 33 
    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

Generate output suitable for use with a patch program
Legend:
Removed from v.126  
changed lines
  Added in v.132
cvs-admin@eby-sarna.com

Powered by ViewCVS 1.0-dev

ViewCVS and CVS Help