Category Archives: aop

The case for AOP in Python

There are many articles out there about AOP and python, and consequently, several AOP solutions for python are offered. The spectrum is broad, ranging from “python doesn’t need AOP” to “python has enough language features to do AOP without framework code” to “AOP works great with python” to “AOP is just another thing built for static languages someone is trying to bolt onto python”.

Someone made a good point back in 2004 on a python mailing list that AOP is a paradigm, not a specific framework, and that if we are going to argue against AOP in python, then it opens the door to arguing over OOP, and in turn, probably every paradigm that we know. Are you ready to throw out python classes and do everything functionally?

When Jim Moore gave his SpringSource presentation at my company a few weeks ago, he gave an excellent description of AOP: its a way to get the computer to help you drop in functionality where its needed, with minimal effort on your part.

Way back in the stone ages, we wrote programs based on how the CPU thinks: one line of code translates directly to one line of CPU instruction. As programs got bigger and bigger, we exceeded the ability to track a whole program. We needed to trim things down into smaller bites, so we could focus on one piece of logic at a time. Someone came up with the idea of combining a class of functionality based on data, and thus OOP was born. New programming paradigm; however, the CPUs are still pretty much the same. Did we worry about this? Of course! There were scores of debates on the merit of OOP. We had the compilers able to translate OOP into sequences of instructions, and just built OOP-aware tools to give us the right visibility. When the next generation of developers arrived, OOP was nothing new, and it has become a part of history.

AOP is another way to avoid DRY (don’t repeat yourself). As we write more sophisticated applications, we still find areas where the same riff of code needs to be sprinkled in several places. If we needed to update the code, we don’t want to edit it in 95 different places, and unfortunately, OOP can’t solve everything, considering its vertical-nature. We have already built compilers than can convert our OOP/AOP/structural programs into a sequence of steps for the CPU to execute. We just need the tools to help us maintain the right perspective. And…we need to wait for the next generation of developers to arrive to cement it into history. In my opinion, writing off AOP as “only needed by java developers” is akin to burying your head in the sand.

It is true that different languages have differing levels on how easily they can support the AOP paradigm. I agree that python is very adept, which is part of the reason that it took less time for me to implement an AOP solution than it possibly took to implement the Java-based one. I would generalize that other dynamic languages are probably quick as well for that.

Python has shown in many articles, that metaclass programming, using decorators, and some of the new python 2.5/2.6/3.0 constructs help as well. It depends on what you are doing. If you are in complete control of all source code, you have more options. Metaclass programming is possible, as are decorators.

Sometimes, you don’t control all the parts. You can read a whole thread, where a Spring Python newbie wanted to add a simple interceptor to an existing library, and trace a certain operation. Spring Python’s AOP module makes this very easy, because it works after the fact. Metaclass programming and usage of decorators would be very hard, unless you were willing to touch the library’s actual code. One key aspect that Spring Python seeks is to be non-obtrusive. Some of the other AOP libraries for python tend to require edits to the code itself.

Regardless of which library you use, the ability to easily intercept code and in turn add functionality based on a controlled pattern is nothing new. We needed OOP to accomplish this in some areas. We need AOP in others. And knowing how to utilize the full extension of a language sums it up. We need the ability to apply functionality at the right time, in the right place, without repeating ourselves.

Spring Python is cooking!

Spring Python is growing fast and I’m excited to be working on this project. I just wanted to list some of the things that shows the many ways this is happening.

First of all, I must point out that we just recently released version 0.8.0. This version contains the newly rewritten IoC container as well as changing from “component” to “object” in the classes and APIs. By separating object configuration from object creation, we have been able to write multiple parser including: the legacy PyContainer format, a new XML format custom built for Spring Python, Spring’s 2.5 XML format, and also a pure python @Object format. We can also reference between input sources with ease.

This release counts as the fourth one made since Spring Python became an official extension back in July. We have made at least one release per month, which if you check out JIRA, will see is current target pace leading up to version 1.0.0. A steady release cycle is a good sign of an active project.

I also have enjoyed answering questions posted in the community forum. I was really excited to be able to help a user who was experimenting with changes to ai4game, a pygame application. He wanted to wrap some objects with AOP. First of all, thanks to this user, we uncovered a bug in Spring Python, and I managed to code the patch immediately and get it out to this user. I like real-world examples because they show me what types of problems people are trying to solve and it also lets me know people are really using this software. It also helps expose bugs and grow the reliability of things.

Another things I’m really excited about is about this year’s Spring One Americas conference. Spring Python is scheduled for a presentation titled Introduction to Spring Python. Even if I’m talking to a relatively empty room, I will be excited to do that.

Also, seeing Russ getting out the word during his presentation at the London Spring Users Group was fantastic!

All of these things make me really glad to be working on Spring Python.