[PEAK] Status of PyProtocols

[Michael Milverton]

Thanks for the reply and sorry about the duplicate message to the list, it's
been a while since I last used a mailing list :) Anyway, I did check out the
AddOn package and I love it, I'm already putting it to great use. I hope you
continue to support it for a long time to come, it's fantastic. I'm using
the abstract base classes too, I must admit to not paying much attention to
this feature, probably because I was using PyProtocols. It's still a little
sad to see PyProtocols rot, it was the best and easiest interface and
adaptation library available for python and I really enjoyed using it.

Keep up the great work,

Thanks
Michael Milverton



On Sat, Mar 19, 2011 at 3:10 AM, P.J. Eby <pje at telecommunity.com> wrote:

> At 06:12 PM 3/18/2011 +0800, Michael Milverton wrote:
>
>> Hi, I love PyProtocols and have used it since about 2005, but since it
>> hasn't been updated in a while I'm kind of curious as to what it's future
>> holds. I am a little hesitant to use it in code now because I'm worried that
>> PyProtocols doesn't have a future.
>>
>
> It really doesn't.  Twisted's old interface system has died and been
> replaced with zope.interface, and the interface/adaptation PEPs are just as
> dead.  Python since 2.6 is using the 'abc' module for interface declaration,
> and PyProtocols doesn't have any support for it.
>
> PEAK-Rules, on the other hand, *does* support ABCs, and the combination of
> abcs, generic functions, and add-ons (see the AddOns project on PyPI) can do
> pretty much anything you could do with PyProtocols (except interoperate
> directly with zope.interface).
>
> About the only thing that's lacking is the ability to actually "adapt"
> something to something else; I do plan to add a generic Interface class to
> support this at some point, but that's really just syntax sugar.
>
> If you write an interface like this today:
>
>  class IFoo(abc):
>      @rules.abstract
>      def some_method(self, blah, blah):
>          ...
>
> Then you can simply say:
>
>    IFoo.some_method(anObj, ...)
>
> instead of:
>
>    IFoo(anObj).some_method(...)
>
> And in an implementation, you simply say:
>
>    class Foo:
>        @rules.when(IFoo.some_method)
>        def some_method(self, blah, blah):
>            ...
>
> to register your implementation.
>
> In other words, It's really only if you're trying to be backward compatible
> with a large code base that you need the additional syntax sugar.
>
>
>
>   Also, would it be hard to remove the speedup setup and just have a pure
>> python implementation?
>>
>
> No, it's optional.  At runtime, if the C code can't be imported, the Python
> code is used in its place.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eby-sarna.com/pipermail/peak/attachments/20110319/1334b2f5/attachment.html