Fixes and changes since PyProtocols 0.9.3

 - Added support to make 'protocols.advise()' operate correctly in a doctest
   or other 'exec' scenario.  'protocols.advice.getFrameInfo()' now returns
   a 'kind' of '"class"' when in a class body being exec'd.

 - 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

 - 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
   degree, and its removal was unopposed.  This feature was an extension to
   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
   is unsuccessful.  'AdaptationFailure' is a subclass of both 'TypeError' and
   'NotImplementedError', so code written according to either PEP 246 or older
   versions of PyProtocols will still catch the error.

 - There is now an 'AbstractBase' class, similar to 'Interface', that can be
   used for the "ABC" (Abstract Base Class) style of interface usage, where the
   interface may contain implementation code, and can be subclassed to create
   concrete implementations.  In previous versions, you could use 'Interface'
   as such a base class, but now calling an 'Interface' object performs
   adaptation rather than instantiation, unless the subclass redefines
   '__init__'.

 - 'Protocol' instances (except for 'AbstractBase' subclasses) are now callable
   with a signature similar to 'adapt()'.  E.g. 'ISomething(foo,*args)' is
   equivalent to 'adapt(foo,ISomething,*args)'.  This convenient API, pioneered
   by Twisted and later adopted by Zope X3, is now available in PyProtocols as
   well.  (Note that as a result of this change, the PyProtocols test suite now
   requires a Zope X3 alpha release or better.)

 - 'setup.py' now accepts a '--without-speedups' global option to disable
   the C speedups module.

 - We now support the latest 'adapter_hooks' protocol provided by Zope X3
   interfaces, allowing multiple interface registry systems to participate
   in Zope interfaces' '__adapt__()' implementation.

 - 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.

 - Defining an adapter from one protocol to another, when that adapter does not
   shorten the adaptation path, would produce a spurious 'KeyError'.

Fixes since PyProtocols 0.9.1

 - Fixed missing unit tests for 'Variation' class, and the two bugs in
   'Variation' that weren't found because of the missing tests.

Fixes and Enhancements since PyProtocols 0.9

 - Added the 'factoryMethod' and 'equivalentProtocols' keywords to 'advise()'.

 - 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'.

 - Added 'protocolForType()' and 'protocolForURI()', that allow you
   to link interfaces by intended semantics, not just by having identical
   instances.  For example, you can use 'protocolForType(file,["read"])' to
   symbolize a file-like object with a 'read()' method, or
   'protocolForURI("some UUID")' to symbolize some documented interface.

   In addition to compact declarations, this also allows a module to refer to
   an interface without importing a specific definition of it.  Then, when that
   module is used in a larger program, the linkage between the symbolic and
   actual forms of the interface can be accomplished semi-automatically.

 - Enhanced Zope 3 support: Now, adapters can be registered between Zope
   interfaces, and any types or instances.  Note, however, that
   interface-to-interface adaptation may not work if a class only declares what
   it implements using the Zope interface API.  This limitation might be able
   to be removed later.  Zope interfaces can now pass a much larger segment of
   the test suite than before.

 - Added 'protocols.Variation(baseProtocol,context=None)'; this
   implements the 'LocalProtocol' example in the documentation.

 - Added 'Adapter' and 'StickyAdapter' convenience base classes.  'Adapter'
   offers a ready-made '__init__()' method suitable for most adapter
   classes, while 'StickyAdapter' instances automatically declare themselves as
   an instance-specific adapter for any object they're used on.  Thus, a
   'StickyAdapter' can maintain its state across 'adapt()' calls for the same
   object, so long as the object can have instance-specific adapters declared.
   (See "Protocol Declarations for Individual Objects" in the reference manual
   for more information on this.)

 - Added experimental support for 'ExtensionClass'; previously, PyProtocols
   could raise bizarre errors and/or behave strangely when 'adapt()' was called
   on 'ExtensionClass' instances.

 - Fixed some problems with the test suite when running under Python 2.3.
   PyProtocols itself worked fine, but the test suite was bitten by two minor
   semantic changes that took effect in 2.3, resulting in lots of error
   messages about ModuleType needing a parameter, and a test failure for
   'checkClassInfo' in the 'FrameInfoTest' test class.

 - Fixed a memory leak in the C "speedups" module that leaked unbound
   '__conform__' and '__adapt__' methods, as well as '__class__' and '__mro__'
   references.  Also, fixed the C code potentially reraising invalid error
   tracebacks under certain circumstances.