Pieces of Mind

AOPython is an AOP (Aspect Oriented Programming) module for Python. AOPython provides a base ‘Aspect’ that can ‘advise’ or wrap function and/or method calls. It also contains a weave function that can weave (apply advice to a subset of- or all functions and methods in) a module, class, or instance. Advice may modify or replace parameters and/or the return value of the advised function or method each time it is called. It can do many other things such as handle exceptions raised by an advised function, collect information on the method call (logging), or obtain and release resources before and after a method is invoked. Download AOPython 1.0.2. Example 1: How to wrap a function

from aopython import Aspect
def negate(x):
    return -x
aspect = Aspect()
negate = aspect.wrap(negate)
negate(2) # advised function call

Example 2: How to weave a class

from aopython import Aspect
class MyObj(object):
    def double(self, x):
        return x * 2
    def tripple(self, x):
        return x * 3
aspect = Aspect()
aspect.weave(MyObj)
myobj = MyObj()
myobj.double(5) # advised method call
MyObj.tripple(myobj, 5) # advised method call

In this release the weave functionality has been enhanced to allow more flexible weaving of callables in modules, classes, or instances. An unweave function has also been added to allow advice to be removed en-mass from an object that was previously weaved. Test coverage was also greatly improved, especially for the weave/unweave functions.

Version 1.0.1 of AOPython is now ready for consumption. If you’ve been using 1.0 I recommend that you upgrade to this version as the API has changed slightly in a non-backwards-compatible way: the order of the first two arguments of the weave function has been reversed (that’s all). Otherwise, the documentation is improved slightly and there are a few other minor changes. See the changelog for more detail. Download: aopython-v1.0.1.zip

Last night I reworked the graphics for the Pieces of Mind design. Before, it was dead. It was the start of a cool idea, but still a bit blah. Tonight, after 35 miles on the bike with Dad and Natalie, I sliced up the new template and updated the style sheet. I like what I’ve come up with so far. I’m still thinking about a few embelishments, but I think it’s mostly done for a while. What do you think? If you’re reading this you probably already know, but for the record I also changed the directory in which the blog is located. I think /pieces is better than /daniel. Still to come, an about-the-author page and maybe I’ll even get around to cleaning up a few more MT templates. Right now that’s all pretty low on the priority list. Good night.

I’ve written a small module called aopython: Aspect Oriented Python. I just wanted to make it public (mostly so I can download it at work). I’ll write more about it later, but for now here it is. Please feel free to make suggestions if you have any.

This article from The Code Project describes a maintainability tradeoff that is realized when any logical layer in a multi-tier application is allowed to access any other layer. In my experience, this tradeoff is often justified by ease of implementation and getting the job done as quickly as possible. The hidden cost of the decision is deferred until the application must be extended. If the extension is large or complex enough it is often easier to rewrite a large section of- or the entire application at that future time. And of course that, in the words of Joel, is “the single worst strategic mistake that any software company can make.”

Well this is my first attempt at a new look and feel. What do you think? There are still quite a few details that need refinement. I’m not sure if I’ll get to the archive templates tonight, and it still looks pretty bad in IE because I haven’t removed all the old MT styles. Stay tuned. [Update 11:12 PM, Monday 06/13/2005] OK. Most of the main templates have been updated. I know there are still a few pages that still need help yet (where is the search results template??), but I might not get to them for a while.

While reading Typing: Strong vs. Weak, Static vs. Dynamic my mind was jogged by this statement:

Pythonic programming style is to use inheritance primarily for implementation; Python’s name-based polymorphism means that you rarely need to inherit for interface

I was reminded of the Java Toolbox article on Why extends is evil. What implications does the “The fragile base-class problem” have with regard to Pythonic style? Q. Is Python evil because extension is the only option (there is no such thing as an interface in Python)? A. No. Python objects can do what that article is talking about: wrap other objects to encapsulate behavior without exposing methods with incorrect semantic meaning. One thought is that Python developers have no need to explicitly define interfaces, they just write code that implements them. I like less code, but I’m still grappling with the idea that, in Python, there is no easy way to see where an interface change will break other code without writing comprehensive unit tests. With Eclipse a change to the interface and a recompile (automatic) will reveal most if not all breakage points within the application (assuming minimal use of reflection and introspection). One very useful aspect of this behavior in Java is the ability to get an idea of the impact of a given interface change–and Eclipse makes it really easy to see that impact as well as to fix the damage once the change is made. Having said all that, interfaces are no substitute for good unit tests. Ahh, but they sure do provide a nice false sense of security…hey, it compiles. With Python the statement “hey, it starts up” only means that the code needed to get your application started is working. Could a tool be written to test Python code for the type of errors that are exposed by Eclipse when a Java interface changes before the change is resolved in the implementation? Maybe an “interface testing module” could be written to detect if an object implements a given “interface”? …but now I’m back to writing my interface in code … I guess any comprehensive test suite would most likely have that information anyway. For reference: encapsulation Interesting, but not really related: Why getter and setter methods are evil and More on getters and setters. Future post: how does the getter/setter problem in these articles relate to Pythonic style?