Aspect Programming Module

[Anand Pillai]

Is there any module/toolkit or framework for doing
aspect oriented programming (AOP) in Python?

For example AspectJ from Xerox park is a framework
which can be used to do this for Java.

Many TIA...

-Anand

 

[Alexandre Fayolle]

Is there any module/toolkit or framework for doing
aspect oriented programming (AOP) in Python?

You may want to try the logilab.aspects package, available at
http://www.logilab.org/projects/aspects/

 

[Will Stuyvesant]

[Alexandre Fayolle, being a good employee]

You may want to try the logilab.aspects package, available at
http://www.logilab.org/projects/aspects/

I am afraid you are serious.

AOP is *not needed* for Python programmers. Plain and simple.

Don't understand? Try this:

"AOP is a contrived way to get around the limitations of a statically
typed language."

Put that on the logilab website. And hire somebody to repair the
broken English over there, it looks really, um...oh well I am not a
native English speaker myself either.

 

[Joe Mason]

[Alexandre Fayolle, being a good employee]
You may want to try the logilab.aspects package, available at
http://www.logilab.org/projects/aspects/

I am afraid you are serious.

AOP is *not needed* for Python programmers. Plain and simple.

Don't understand? Try this:

"AOP is a contrived way to get around the limitations of a statically
typed language."

Care to explain that? What I've seen of AOP seems like a very dynamic
design philosophy.

Joe

 

[Donn Cave]

[Alexandre Fayolle, being a good employee]
You may want to try the logilab.aspects package, available at
http://www.logilab.org/projects/aspects/

I am afraid you are serious.

AOP is *not needed* for Python programmers. Plain and simple.

Don't understand? Try this:

"AOP is a contrived way to get around the limitations of a statically
typed language."

Care to explain that? What I've seen of AOP seems like a very dynamic
design philosophy.

Have you been through the materials referred to there?
I didn't spend much time on it, but I didn't immediately
recognize anything from the last time I heard about AOP,
so I was led to wonder if it's a different notion going
by the same name.

The one I remember allows objects to inherit from containers,
more or less. Your widget for example might inherit some
drawing parameters from the window it belongs to. I'm probably
getting it mostly wrong, but then I wasn't very excited about
the idea. OOP is scary enough without compounding it this way.

Donn Cave, (e-mail address removed)

 

[Joe Mason]

Have you been through the materials referred to there?
[http://www.logilab.org/projects/aspects/] I didn't spend much time on
it, but I didn't immediately recognize anything from the last time I
heard about AOP, so I was led to wonder if it's a different notion
going by the same name.

No - I don't have any particular need or interest in AOP at the moment,
so I haven't really looked at it.

The one I remember allows objects to inherit from containers,
more or less. Your widget for example might inherit some
drawing parameters from the window it belongs to. I'm probably
getting it mostly wrong, but then I wasn't very excited about
the idea. OOP is scary enough without compounding it this way.

The only example I've read was an intro using AspectJ
(http://www-106.ibm.com/developerworks/library/j-aspectj/) which logs
every function call. That doesn't seem too scary.

Joe

 

[Hung Jung Lu]

AOP is *not needed* for Python programmers. Plain and simple.

Don't understand? Try this:

"AOP is a contrived way to get around the limitations of a statically
typed language."

I beg to differ.

Python does not even have codeblocks. So how can you say AOP is not
needed for Python programmers?

It's another issue that current AOP "products" a la AspectJ are trash.
But the concepts from AOP are not only correct, but really necessary
in large-scale projects.

-----------------

Most people have a superficial understanding of AOP. I don't blame
them, since the papers by Kiczales et al. and probably all other
papers on AOP are a mess.

Anyway, I have talked about AOP long enough in the Python mailing
list. I won't repeat here.

I do have a few comments:

(a) AOP should have been called SOP (Subject Oriented Programming)
from a start.

(b) AOP is code factorization in the horizontal direction:
organization of code by action, not by data.

(c) AOP is in a way the Fourier Transform of OOP.

(d) AOP will not be popular until there is proper IDE/code-viewer or
some other novel techniques at runtime. It's coding in three
dimensions, and humans are only good with two. Asking an average
programmer to factorize code manually by objects (vertically) and by
subjects (horizontally), and use metaprogramming for weaving (a la
functional programming), is a bit too heavy. Until the day when all
this is done simply by mouse clicks (like editing the header and
footer information of a Microsoft Word document), AOP will be used
only by advanced programmers addressing large and complex projects.

regards,

Hung Jung

 

[Max M]

Python does not even have codeblocks. So how can you say AOP is not
needed for Python programmers?

I am probably rather dense, but I have not seen aspect oriented examples
that could not have been done with simple mixins.

Isn't it needed in Java because it doesn't have multiple inheritance?


regards Max M

 

[Alexandre Fayolle]

Will Stuyvesant feels like trolling:

[Alexandre Fayolle, being a good employee]

+1 point for ad hominem attack.

I am afraid you are serious.

I am. Deadly serious. I even took part in the implementation of the
module. And I'll tell you a secret. Even though logilab.aspect was more
a proof of concept implementation, we actually use it, especially the
logging and contract aspects, in production code.

AOP is *not needed* for Python programmers. Plain and simple.

Oh. And we're all supposed to take your word for it then. Such useless
comments are not needed by the Python community. Plain and simple.

Don't understand? Try this:

+1 point for implying I'm an idiot.

"AOP is a contrived way to get around the limitations of a statically
typed language."

Do you have anything to offer besides blunt dogmatic assertions? Could
you please quote your sources, or provide some supportive arguments.

The goal of AOP is "separating crosscutting concerns". This has nothing
to do with static/dynamic typing. It is a design problem. I think you
should read a bit on the topic before making a fool of yourself. Here
are a few links, for your education:

The original idea: http://www.parc.xerox.com/csl/groups/sda/publications/papers/Kiczales-ECOOP97/for-web.pdf
Aspect home page: http://www.aosd.net
aspects links: http://www.volantec.biz/aspect.htm
AspectJ tutorial: http://www.eclipse.org/aspectj/
Crtitical analysis: http://citeseer.nj.nec.com/highley99aspect.html

Other projects provide AOP facilities for Python:
Pythius: http://pythius.sourceforge.net/
PEAK: http://peak.telecommunity.com/Articles/WhatisPEAK.html

Put that on the logilab website. And hire somebody to repair the
broken English over there, it looks really, um...oh well I am not a
native English speaker myself either.

Thank you for this very constructive remark. I hate to admit it, but
this is probably the most sensible thing you wrote in your post, though
the Netiquette explicitely frowns on such remarks.

 

[Alexandre Fayolle]

I am probably rather dense, but I have not seen aspect oriented examples
that could not have been done with simple mixins.

Hi Max,

I'm probably rather dense too
How do you implement the logging aspect with a simple mixin?

(the logging aspect prints a statement before and after each method call
of a class instance)

 

[Will Stuyvesant]

[Joe Mason]

Care to explain that? What I've seen of AOP seems like a very dynamic
design philosophy.

Dynamic indeed. And that is a problem for statically types
programming languages like Java.

To add logging capabilities to an instance object of a Python class
you simply add a function/method that does the job. Add it as an
attribute to the object itself, or to the object's __class__, or to
anything else you can get at via the object and its attributes.

You can not do that in Java because the Java class definition is
"fixed", you can't change it. But they still want to do it, so they
use a complex AOP framework to do it in.

 

[Joe Mason]

I am probably rather dense, but I have not seen aspect oriented examples
that could not have been done with simple mixins.

Isn't it needed in Java because it doesn't have multiple inheritance?

AOP is a design technique, not just a set of tools. If it's true that
you can just use simple mixins in Python to get the same effect as
ApectJ, then you can say, "AOP is implemented on Python with mixins, but
Java requires language extensions such as AspectJ." That doesn't mean
Python doesn't "need" AOP - nobody really "needs" it, they just find it
a useful way of approaching problems, and moving to Python doesn't make
it a less useful approach. In fact, if it's easier on Python, it's more
useful.

Joe

 

[Joe Mason]

[Joe Mason]

"AOP is a contrived way to get around the limitations of a statically
typed language."

Care to explain that? What I've seen of AOP seems like a very dynamic
design philosophy.

Dynamic indeed. And that is a problem for statically types
programming languages like Java.

To add logging capabilities to an instance object of a Python class
you simply add a function/method that does the job. Add it as an
attribute to the object itself, or to the object's __class__, or to
anything else you can get at via the object and its attributes.

But that doesn't address the calling of the new function. You still
have to either manually insert calls everywhere, or set up a system
which notices when new functions are added and inserts calls to them as
needed. Once you've done that - poof! Aspect Oriented Programing!

Joe

 

[BeatBoxx83]

please, give me some pointers on begenning. I would love to learn how to start.
thank you

 

[Yermat]

Hi Max,

I'm probably rather dense too
How do you implement the logging aspect with a simple mixin?

(the logging aspect prints a statement before and after each method call
of a class instance)

Does it help ?

class LoggerAOP(object):
def __init__(self, f, name):
self.f = f
self.name = name

def __call__(self, *args, **keywords):
if callable(self.f):
print "calling %s" % self.name
result = self.f(*args, **keywords)
print "end of call %s" % self.name
return result
raise TypeError, "%s not callable" % self.name

class MyClass(object):
def __init__(self, name):
self.name = name

def foo(self, a):
return "%s say hello to %s" % (self.name, a)

m = MyClass("Yermat")
print 'm.name:', m.name
print 'm.foo:', m.foo("world")

m.foo = LoggerAOP(m.foo, 'foo')

print 'm.name:', m.name
print 'm.foo:', m.foo("world")

 

[Alexandre Fayolle]

Does it help ?

Well, yes and no. I agree that this is how AOP can be made to work in
Python (aand your implementation is not conceptually very different from
logilab.aspect (except that the module has some entry points for
choosing which methods are tied to the aspect)

However, I would not call this a "mixin" (which was the key word in my
question). My vision of a mixin implies (maybe wrongly) some
responsibilities to be added or customized through multiple inheritance
to a given class by a mixin class. This supposes that the originial
class was designed with the mixin in mind.

 

[Yermat]

Well, yes and no. I agree that this is how AOP can be made to work in
Python (aand your implementation is not conceptually very different from
logilab.aspect (except that the module has some entry points for
choosing which methods are tied to the aspect)

However, I would not call this a "mixin" (which was the key word in my
question). My vision of a mixin implies (maybe wrongly) some
responsibilities to be added or customized through multiple inheritance
to a given class by a mixin class. This supposes that the originial
class was designed with the mixin in mind.

Oups sorry !
So maybe something like the following.
In fact, I'm really wondering what is really AOP. It seems just like
code factorization after all and use it only on some instance !

class LoggerAOP(object):
def __init__(self, f, name):
self.f = f
self.name = name

def __call__(self, *args, **keywords):
if callable(self.f):
print "calling %s" % self.name
result = self.f(*args, **keywords)
print "end of call %s" % self.name
return result
raise TypeError, "%s not callable" % self.name


class FunctionLoggerClass(object):

def __getattribute__(self, attrName):
realAttr = object.__getattribute__(self, attrName)
if callable(realAttr):
return LoggerAOP(realAttr, attrName)
return realAttr

class MyClass(object):
def __init__(self, name):
self.name = name

def foo(self, a):
return "%s say hello to %s" % (self.name, a)


class SpecMyClass(FunctionLoggerClass, MyClass):
pass

m = SpecMyClass("Yermat")
print m.name
print m.foo("world")

 

[Will Stuyvesant]

I apologize for the earlier post, written in a bad mood.

I recently had to listen to a scientific talk about AOP and I did
not like the talk...

It seems to me there are *numerous* ways to do AOP in Python.

Years ago (1997?) GvR mentioned using __getattr__() to trap method
calls, and since then also metaclasses have been added to do things
like adding logging capabilities.

A thread from 2003 with Alex Martelli: http://tinyurl.com/2o267
is even specifically about logging.

I am not an expert on this style of programming. Perhaps you are
right that an aop or mixin or ... module could be useful in Python.
Show use cases? For example:

The following code:

class MyLogger:
def log(self): pass
class MyClass: pass

addMe(MyClass, MyLogger.log)

would result in MyLogger.log being called after each call to a
method of MyClass? And then you need others that add things
*before* method calls. Etc. etc. What are good usage examples?

underscore-programming-indicates-early-design-errors-ly y'rs - will

 

[Peter Hansen]

What are good usage examples?

I would be very interested to hear some real-world and real useful
use cases for AOP as well. So far, the logging example seems to
be put forth so often that I'm starting to suspect that's the
*only* "useful" thing people are doing with it.

From direct personal experience, could some AOP folks please
point out some compelling use cases so that the doubting
Thomases (and Wills, and Peters) can better understand and
accept the idea of AOP as being more than just a few fringe
cases?

(The logging one actually annoys me: the only time I've ever
wanted such logging was when debugging very complicated problems,
and since switching to TDD I have never encountered anything
that even remotely made me consider writing such logging wrappers
again.)

-Peter

 

[Diez B. Roggisch]

The other one that springs to my mind is the role rights/permissions
example.