ANN: snake-guice Preview - A Dependency Injection Framework

snake-guice is a dependency injection framework for Python. It has been heavily inspired by google-guice.

snake-guice is still in development and will not be ready to be used in production environments for a few weeks. I’m putting this out there in hopes of getting constructive feedback. Unfortunately the documentation is non-existent so the best place to understand how to use snake-guice is from the unit tests. The API tests are the best examples.

If you don’t already know about dependency injection or how it helps then this project may not be for you just yet.

More to come…

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • Technorati
September 8, 2008 | Filed Under python, guice 

Comments

5 Responses to “ANN: snake-guice Preview - A Dependency Injection Framework”

  1. Kevin Dangoor on September 8th, 2008 12:53 pm

    Hey David,

    If this wasn’t coming from you, I’d assume someone from Javaland just stopped by Pythonland and wanted to bring a favorite tool along for the ride.

    I’m assuming that you’re making snake-guice based on some real need… for me, I haven’t really seen a need for DI in Python. Testability is one of the things DI proponents like to cite, but that’s not an issue in Python, because of monkeypatching. (I’m not a fan of monkeypatching in production, but I’m fine with clear use of monkeypatching in tests).

    So is the value in the ability to rewire things? What’s your main driver for this (at least as far as you’re at liberty to say :) ?

    Kevin

  2. dstanek on September 8th, 2008 1:20 pm

    @Kevin

    There are a few major wins IMHO:

    Testability: Even though monkey patching works it isn’t pretty. I have wasted quite a few hours trying to find out why my tests fail when run together, but succeed individually.

    Good Application Design: The real reason that testability is better is that DI promotes a style of application design that is very loosely coupled. In general this is a good thing. Now using this project doesn’t mean that your application is well designed, but it is another tool.

    Polymorphic Goodness: Imagine an application consisting of a few hundred thousand lines of code that is used across many different websites. What if you wanted to change a business rule on just one of those sites? You could solve this in many ways, but DI is just the one I like best so far. At application startup time I can configure the correct business rule implementation very easily.

  3. Kevin Teague on September 8th, 2008 3:49 pm

    If you haven’t checked out the Zope Component Architecture, you may find that project interesting. It doesn’t use DI and IoC terminology, but it does achieve many of the same goals that the Java DI frameworks do.

    http://pypi.python.org/pypi/zope.component

  4. Justus on September 8th, 2008 9:24 pm

    I’m also curious about DI’s place in python. It is huge in Java-land but not something I ever felt a strong need for in Python.

    I’m not sure I see how DI solves your problem of “tests work if they run individually but fail together”. I’ve had that happen plenty of times with DI in Java. Some unit test somewhere registers some mock thing with the DI injector and then some other unit test later on ends up getting that left over mock.

    I’ve never been convinced on the polymorphic goodness front either but that’s a personal opinion I reckon :-)

  5. Article Help - Dependency Injection in Python : David Stanek’s Digressions on January 1st, 2009 9:54 pm

    […] I believe dependency injection can improve the design and quality of Python applications. It seems this idea is somewhat controversial. My previous post invoked a wide variety of responses. (It was the first time I got email resembling hate mail It seems that a longer and more detailed explanation may be helpful. […]

Leave a Reply