Consuming AMQP/RabbitMQ messages in Python is simple if you use Sparkplug. I read “Building RabbitMQ apps using Python“, and there’s just too much code in the monitor method and the separation of concerns aren’t very clear.

With Sparkplug, you create a configuration file, then define Consumer class to handle each message. As messages are pushed into the queue, Sparkplug will call your class and you decide how you want handle the message in the __call__ method. The great thing about this is that all the connection logic is removed from your code letting you concentrate on how you want to handle each message.

Now you can run your app using sparkplug --daemon consumer.ini. Configuration is boring, so I’ve left the consumer.ini out of the blog post and put it up on github instead.

Jesse has written a great blog post on using test builders to improve the expressiveness of unit tests. He has convinced me that builders are useful and that they provide an easy way to construct objects that are in a valid state. Testing can be hard; I find defining a method for each of the object’s properties to be tedious and repetitive. This is especially problematic if you’re working with an object with dozens of properties.

To balance expressive with conciseness, I’ve refactored the builder to use Python dictionaries

I find this code to be just as expressive, easier to use and most importantly not repetitive.

Coming from a .NET background and having applied SOLID principles to software development, I was surprised by the lack of inversion of control containers for Python.

The few discussions I read online implied that Python doesn’t need an IoC framework because it is a dynamically typed language.  Dynamically typed languages eliminate the need to use interfaces, they do not do away with the need for inversion of control.

IoC is used to decouple components of an application, remove direct dependencies so that replacing a component will not have a side effects on the rest of the system.  As Dave Thomas explains

a DI application is written as a set of loosely coupled components. These components contain no knitting code: nothing in the application code itself is responsible, for example, for making sure that the necessary objects somehow get an instance of the database connection. Instead, the components all run in a container. This container is given a description of the knitting to be done (typically using an XML file). The container then instantiates objects and sets them into components that need them

I’m new to the language and there maybe a more “pythonic” way to handle inversion of control than using a container. Here is small and contrived example of inversion of control using Pinsor, a IoC container in Python. Those coming from a .NET or Java background will find Pinsor easy to use, but slightly lacking in features.