[rabbitmq-discuss] py-amqplib being reworked

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).
> 
> Regards,
> 
> Michael Arnoldus

Hi Michael..

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

	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.

	Barry