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.<div>
<br></div><div>Keep up the great work,</div><div><br></div><div>Thanks</div><div>Michael Milverton<br><div><br></div><div><div><br><br><div class="gmail_quote">On Sat, Mar 19, 2011 at 3:10 AM, P.J. Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">At 06:12 PM 3/18/2011 +0800, Michael Milverton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
If you write an interface like this today:<br>
<br>
class IFoo(abc):<br>
@rules.abstract<br>
def some_method(self, blah, blah):<br>
...<br>
<br>
Then you can simply say:<br>
<br>
IFoo.some_method(anObj, ...)<br>
<br>
instead of:<br>
<br>
IFoo(anObj).some_method(...)<br>
<br>
And in an implementation, you simply say:<br>
<br>
class Foo:<br>
@rules.when(IFoo.some_method)<br>
def some_method(self, blah, blah):<br>
...<br>
<br>
to register your implementation.<br>
<br>
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.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, would it be hard to remove the speedup setup and just have a pure python implementation?<br>
</blockquote>
<br></div>
No, it's optional. At runtime, if the C code can't be imported, the Python code is used in its place.<br>
<br>
</blockquote></div><br></div></div></div>