Browse DevX
Sign up for e-mail newsletters from DevX


Dig Deep into Python Internals, Part 2

Advanced techniques such as metaclasses, code injection, and call-stack walking harden Python for the enterprise. One novel use of Python's dynamic nature allows you to add private code access checking. Follow along to learn how.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

his article is the second in a two-part series that digs deep to explore the fascinating new-style Python object model, which was introduced in Python 2.2 and improved in 2.3 and 2.4. The object model and type system are very dynamic and allow quite a few interesting tricks. In part one I described the object model and type system, explored various entities, explained the life cycle of an object, and introduced some of the countless ways to modify and customize almost everything you thought immutable at runtime. In this article I will contrast meta-classes with decorators, explore the Python execution model and explain how to examine stack frames at runtime. Finally, I will demonstrate how to augment the Python language itself using these techniques. To do this I introduce a private access-checking feature that can be enforced at runtime.

Meta classes vs. Decorators
Philip Eby published a great article about Python 2.4 decorators in the May 2005 issue of Dr. Dobb's Journal, which I recommend if you want to understand them thoroughly. In brief, decorators are callable objects that accept the function they decorate as their sole argument. When a decorated function is invoked its decorator is executed. Most decorators will do something before and/or after invoking the original function. Decorators compete with meta-classes in the same evolutionary niche. Decorators have several advantages over meta-classes:

  1. Decorators can be applied to every function (meta-classes can modify only class attributes)
  2. Multiple decorators can be applied to a single function (each class can have only one meta-class)

On the other hand, decorators are much more intrusive. The presence of a decorator is visible in every decorated function. Meta-classes are much stealthier, especially when applied via a base class. This may be good or bad depending on the case. Decorators shine when you want to put different decorators on different functions and when you mess with them frequently (e.g. adding and removing decorators). It is very easy (once the decorator itself is defined) to add and remove the @decorator attribute.

Meta-classes beat decorators to the punch when it comes to applying a "decorator" to a group of methods across an entire class hierarchy. Adding new classes and new methods to the hierarchy doesn't require any "meta-effort" since the meta-class will be applied by virtue of being attached to the base class.

Aspect-oriented programming is right up the decorators/meta-classes alley. Consider an aspect that tries three times to execute a function that throws an exception before giving up. This kind of policy could be useful for functions that exchange information across the network and would like to overcome temporary disconnects or delays. Let's see how it can be implemented using meta-classes and decorators.

def tryThrice(func): def tripleTry(*args, **kw): for i in xrange(0,3): try: return func(*args, **kw) except: if i == 2: raise return tripleTry

The 'tryThrice' function is a factory function that implements the three strikes aspect. It accepts any function and returns a function called 'tripleTry' that executes it up to three times. If the executed function raises an exception, 'tripleTry' catches it and tries again and again. It gives up only after three failures by re-raising the exception. Note this interesting technique - A factory function that defines a nested function and binds it to a supplied input function, returns the bound nested function. This is not merely the equivalent of a function pointer in C.

The test subject will be a class called Raiser with a method called ’fail’ that prints 'sorry, failed again' and then raises an exception. When this method is given to 'tryThrice' the output looks like:

sorry, failed again sorry, failed again sorry, failed again RaiserException occured. too bad

So, the goal of this exercise is to take a class called Raiser with such a ’fail’ method and apply the 'tryThrice' aspect to it for every invocation using two different methods: via a meta-class and via a decorator.

The following sample code shows the metaclass approach. The meta-class ('Metaclass') has an __init__ method that gets the same class as input parameter 'cls'. It iterates over all its attributes (the dict parameter) and replaces each FucntionType attribute (only 'sorry, failed again' in the case of 'Raiser') with the result of 'tryThrice', which is the 'tripleTry' function bound to the original method. Hooking up the meta-class to the Raiser class is as simple as '__metaclass__=Metaclass' (first line of Raiser). I could hook the meta-class through a base class—which is arguably more elegant and allows you to apply the same meta-class to multiple classes without forcing all of them to import the metaclass's module—but I preferred the direct approach in this case.

import types class Metaclass(type): def __init__(cls, name, bases, dict): methods = [item for item in dict.items() if type(item[1]) is types.FunctionType] for name, method in methods: setattr(cls, name, tryThrice(method)) class Raiser(object): __metaclass__=Metaclass def fail(self): class RaiserException(Exception): def __str__(self): return "RaiserException occured. too bad" print 'sorry, failed again' raise RaiserException() if __name__ == '__main__': try: Raiser().fail() except Exception, e: print e

The next bit of code shows the decorator approach. All you have to do is annotate 'fail' with '@tryThrice' to get the exact same effect.

import types class Raiser(object): @tryThrice def fail(self): class RaiserException(Exception): def __str__(self): return "RaiserException occured. too bad" print 'sorry, failed again' raise RaiserException() if __name__ == '__main__': try: Raiser().fail() except Exception, e: print e

Thanks for your registration, follow us on our social networks to keep up-to-date