[PEAK] Status of PyProtocols

[Michael Milverton]

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. Also, would it be hard to remove the
speedup setup and just have a pure python implementation?

Kind Regards
Michael Milverton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eby-sarna.com/pipermail/peak/attachments/20110318/a6b8f17e/attachment.html

[P.J. Eby]

Post by Michael Milverton
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.

Post by Michael Milverton
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.

[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

Post by P.J. Eby

Post by Michael Milverton
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.
@rules.abstract
...
IFoo.some_method(anObj, ...)
IFoo(anObj).some_method(...)
@rules.when(IFoo.some_method)
...
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

Post by Michael Milverton
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