Article Help - Dependency Injection in Python

DI is fundamental for me as a TDD developer. I can't find a better way to manage dependencies among collaborators. No matter if it is Python, Java or C#. Test driving the software changes it all.
By the way, Pinsor is very nice: http://www.carlosble.com/?p=375</p>

Juri Pakaste did an article for Python Magazine that might be useful as background material: http://pymag.phparch.com/c/issue/view/79</p>

I think DI provides the right level of indirection that lets you write simple apps, and then later layer on useful services. As project lead for Spring Python, I have found the ability to apply AOP interceptors to already written apps makes it easy to apply transactions to business logic, put security in place where it wasn't before, and convert my simple app into a multi-node app very easy without altering the method signatures or original business code.

If you have ever coded database transactions, things can get messy. And you have to do it right to handle errors appropriate. With DI, it is easy to plug in a transactional interceptor without the business code having to be aware of it. The only part of your app that has to be in the know is the part that launches your app, because it needs to launch the DI container which holds your blueprints.

The risk of using the term "framework" is that many people interpret it to mean "extend my classes" to get the power. Spring Python provides a DI library that does NOT require you to extend any classes. Basically, it promotes usage of DI principles without the major requirement of hanging your whole application off the framework.

There is no arcane syntax involved. You can pick to create your objects using constructor calls to init, or just setting object properties by name. You may be assuming I'm talking about some XML definition. True, I have one, however, this is python, so why use XML at all? That is why I also wrote a DI container that uses pure python code and a decorator. Create your objects just like you would normally, only now harvest the benefits of have a central place to see how your components are wired together.

Hi Dave - it's been a while :)

I took a crack at a DI framework for Python several years back (presented at one of the Clepy meetings in its early stages). Maintenance has fallen by the wayside over the past two years, but I came to two conclusions as I worked (and continue to work, when I can) towards v1.0:

(1) Python is very well-suited for developing and using a framework approach for DI.
(2) Whatever that framework is - if it's going to fundamentally change the way existing code is written and maintained (e.g. forcing the programmer to use arcane syntax or exotic implementation patterns), then it's NOT a good idea.

For the record, what I ended up with is maybe a bit closer to "Service Locator" than DI, but it's essentially the same idea with the same benefits.

@dstanek

Excellent. Then in your article I look forward to seeing a clear explanation of "done correctly" and what exactly you mean by "don't ... apply."

@Ryan

Yup. I just don't think they apply when done correctly.

@dstanek

Right. But isn't snake-guice a framework? And, as such, potentially susceptible to the criticisms levied by Jamis against DI frameworks in dynamic languages?

@Ryan

Thanks for the info. I agree with much of the article. In the end the author uses DI just not a framework.

Jamis Buck was a big enthusiast of bringing dependency injection to Ruby, wrote two Ruby DI frameworks, and ultimately decided it was the wrong thing to do. See

http://infozerk.com/averyblog/rubyconf-08-jamis-buck-recovering-from-the-enterprise/

and

http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming

Now, Python is not Ruby, but for the purposes of his discussion, the differences between the languages are not that relevant (in my mind anyways).

Anyways, I think to argue for DI in python, you need to show how the benefits clearly outweigh the issues he's identified.