[rabbitmq-discuss] py-amqplib being reworked
bp at barryp.org
Tue Dec 2 01:31:43 GMT 2008
Michael Arnoldus wrote:
> Hi Barry,
> This is interesting work. We are currently using the Qpid M1 python
> client and aren't entirely satisfied, especially with error handling. As
> we're about to decide on a new client library py-amqplib has been
> considered. Until now it hasn't really been an option due to the lack of
> support for timeout, basic.reject etc. However with this latest message
> I want to consider it again.
> The other candidate we have considered is naturally the Qpid M2.1 or M3
> pythin lib. Do you have any idea about the difference? If not then maybe
> you can tell me what let you to write py-amqplib instead of using the
> Qpid client? I remember in the beginning something about specifically
> going for a unthreaded library, but it seems you have given that up
> (which incidentally makes very much sense in my book considering the
> AMQP protocol).
> Michael Arnoldus
Sorry, haven't looked at Qpid in a long time, so can't say anything
about differences between various versions.
I started py-amqplib instead of using Qpid because of a few things I
didn't like (keep in mind these criticisms are from what I saw over a
year ago) ....
The documentation and examples were non-existent or unhelpful,
or flat-out wrong/broken.
I thought having to parse an XML spec file took too much time.
I wanted something that could quickly start and fire off just a
message or two.
I thought the code was basically un-Pythonic, seemed like
something some Java writers had slapped together so they
could test their Java code. I wanted something with a
I didn't want something that *had* to use threads, because I
wanted to use it with Python embedded in an SMTP server, and
figured that would just make things less reliable when things
*really* needed to be reliable.
I haven't given up on single-threadedness, the new code just has an
option to use a helper thread. Without that option enabled the code
still runs much like the old version - which works well for simple needs.
If you're looking for *good* error handling, I don't think I have
anything like that yet. The exceptions that are thrown aren't well
planned out or consistent.
The timeouts and handling of returned messages also need much polishing,
I haven't quite worked out how the API for that should work. What's
there now seems to function but is a bit clumsy to use.
More information about the rabbitmq-discuss