Posts about Python

Book Review: Python Testing Cookbook

toby ho — Tue, 02 Aug 2011 12:47:37 -0500

This is the second of 2 Python book reviews. The book is Python Test Cookbook.

This book is a very complete overview of all aspects of testing with Python. It starts out with simple unit tests, then moves on to nose, BDD, Doctest, acceptance testing, coverage, continuous integration, and smoke tests and load tests. The last chapter of the book gives you a number of advices for starting out with testing.

The Good

I enjoyed this book in that it gave me a birds-eye view of all the tools and techniques that are there for Python, many of which I didn't know about before. I also learn new things about things that I had already used before. Lastly, I liked the last chapter in which the author gives us his heart-felt experiences with testing. Although I don't agree with everything he says(running your tests once a day is way too few), there is a lot of good advice there as well as good stories.

The Bad

One thing that I don't like about this book is that it's too code heavy. Pages and pages of code are print onto the page with only interleaving explanations. I mostly skimmed those parts because reading code line-by-line like that is just too boring. Code is simply not meant to be read in a linear fashion. When you read code, you jump between different files rapidly in order to fill the in missing context as you try to gain an understanding of the code. An even better aid in reading code is the ability to execute the code and instrument it with print statements or stop it with the debugger and inspect the program state. So, in summary, code-heavy books just doesn't make sense. Perhaps instead of writing this as a book, we should just point the readers at a code repository?

The second problem is that not enough was done to motivate each technique that was used. The author didn't properly motivate why one should write unit tests at all. Or why use a given technique listed in the book. Only cursory introduction is given for each technique or tool, and then it was straight to the code. We dwelled too much time on the how and not on the why, which makes this book very unfriendly to beginners.

Summing Up

Overall, I would not recommend this book to beginners or people who are looking for an introduction to testing. I am on the fence about recommending it at all, but it might be helpful for people who are already familiar with test driven development but just haven't been doing it with Python.

Book Review: Python 3 Web Development - Beginners Guide

toby ho — Thu, 21 Jul 2011 23:54:14 -0500

I just finished reading Python 3 Web Development - Beginners Guide by Michel Anders and here is my book review.

Michel Anders is no doubt a brilliant programmer. He has managed to go through HTML, Javascript, jQuery, jQuery plugins(both using and writing), jQuery UI, CSS selectors, CSS 3, Python, CherryPy, SQL and SQLite, unit testing, writing your own ORM, and Python meta-classes all in one book! Which is the problem with this book. I doubt any one who qualifies as a beginner will be able to get any further than chapter 2. I believe the author made the mistake of not putting in enough thought about his audience when writing. But, before making my final remarks, I'll give it proper treatment by commenting on each of the chapters.

Chapter 1

Chapter 1 explained the authors reasons for choosing the tools that he did, and boy were there a lot of choices to be made. Here were the choices:

Web framework: CherryPy
Language: Python 3
Javascript Library: jQuery and jQuery UI
Database: SQLLite
ORM: None. He's rolling his own
Revision Control: svn

There are a lot of high level talk about the rationale of each choice and why he made them. It was a bit strange that he put the choice of using Python after the choice of using CherryPy. The first chapter is quite intimidating for beginners - there is really lots to consider when building a web app. He admits it too, but he puts in a lot of encouraging words to encourage the reader to stay focused.

Chapter 2

Chapter 2 went through the exercise of building a web-based spreadsheet application, a la Google Docs. The goal is ambitious, especially for a "hello world" program. I wondered how he was going to pull it off.

The Author covered CherryPy, jQuery/CSS selectors, a jQuery plugin called jEditable, wrote his own jQuery plugin that builds a spreadsheet which uses jEditable, CSS 3 and HTML all in this chapter. The amount of Javascript in this chapter really surprised me because in the who-is-this-book-for section, it says "introductory level knowledge of JavaScript might be useful, but is not strictly necessary". He simply tried to cram too many things in, explaining each technology only cursorily as he encounters them. I am pretty sure that he lost almost all readers in his audience with this chapter.

The Rest of the Chapters

Since we've already lost almost all readers I will place less emphasis on chapters 3-10. Basically, it is more of the same: trying to cram too much information into his readers' minds too quickly. These chapters whirl-wind tour the following:

Writing an authentication handler, and then later authorization within CherryPy
Using the file system as storage
Using SQLite to replace the file system as as storage
Using SQL directly to manipulate and query the database
Ajax and lots more of jQuery and jQuery UI
Unit testing in Python
Building a hand-rolled ORM, and then improving it using meta-classes, where the phrase "make your head explode" was used
Adding a CRUD interface to the system for his CRM, and then refining the CRM.

The further you get in the book, the larger blocks of code were put on the page, and the author just tries to talk through what is going on. I skimmed most of these chapters because when you are explaining code that is so dense, it is easier to read the code itself - which I often resorted to - than to read the prose.

Conclusion

Unfortunately, I cannot recommend this book. Reading from the book title, the audience is a Python programmer, perhaps beginner to intermediate, who is beginning in building web applications. This book will send this programmer away crying. I think perhaps a more fitting title for this book is "A Coding Cowboy's Journey In Web Development with Python 3".

Python Book Reviews Forthcoming

toby ho — Fri, 15 Jul 2011 10:38:09 -0500

The kind folks at PacktPub are letting me review a couple of Python books. Hooray! They are

Look for my reviews of them in the near future.

Smart Parameter Checks in Python

toby ho — Thu, 24 Mar 2011 22:27:29 -0500

While I really enjoy using Michael Foord's Mock library, there is one thing missing and I thought would be a fun project to add - which is the subject of this post.

Fun with Parameters

Python has the most sophisticated function parameter calling mechanics I've ever seen. Given a function f

def f(a, b):

    return a + b

You can either call it like normal(positional parameters)

f(1, 2)

or by keyword parameter

f(a=1, b=2)

With keyword parameters, the position doesn't matter anymore, so the above call is equivalent to

f(b=2, a=1)

You can even mix positional and keyword parameters, as long as you put all the positionals first

f(1, b=2)

So, all the ways I've listed of calling the function f with the parameter a as 1 and b as 2 will have the same functional behavior, given what we know of the signature of the function. So, it would be logical that the mock library would consider

f.assert_called_with(a=1, b=2)

a passing assertion even though in reality it was called as

f(1, 2)

but alas, it does not.

With that, it was my mission to make this happen!

Proof-of-Concept

First I created a prototype/proof-of-concept. See code here. Using

inspect.getargspec(self.func)

I was able to get all the info about the signature of a function I needed. When a function call actually comes in, my callable receives them as

def __call__(self, *args, **kwds):

at which point, I resolve all the parameters with the parameter list in the function signature(I called this "combining" the args)

First, by walking the actual positionals (the args array coming in) and cross referencing them with the ones in the function signature. After this is done, we basically converted the positionals into named form - as a dict.
Then merge everything in kwds into the same dict. So we have one unified dict with all the actually parameters and keyed by parameter name.
If there are any left over from the variable position args, they are stored in an extras list.

Now, with this information handy, we can actually do our own safe parameter checking, and we should! So when a call is made, I also check if all the required params have been provided, whether there are any unexpected params and so forth, and actually raise some TypeErrors like a real function if need be.

But the better part is what comes next - we can now implement the assert_called_with with these new semantics. When a call to assert_called_with is called, I "combine" the args coming into that call, and check if they match the previously made function call. It's that simple!

Working in Python-Mock

Well great. But we still can't use for the Mock library. So I did some more hacking on a branch of Foord's code. Not sure it's the cleanest code, but it now works if you want to try it out

hg clone https://airportyh-python-mock.googlecode.com/hg/ airportyh-python-mock

The way you use it with the Mock library is through mocksignature.

from mock import mocksignature

mocksignature wraps a function that you pass it and uses the signature of that function as a guide. Given the function f that we had previously, you can do

f = mocksignature(f)

now call it

f(1, 2)

and then checking the associated mock with a different call style

f.mock.assert_called_with(a=1, b=2)

should now pass.

Cheers!

Python-Style OO in Javascript

toby ho — Wed, 16 Jun 2010 23:47:47 -0500

A while a go I wrote a post on Prototype Inheritence in Python. This time, I am somewhat going the opposite direction. That's right: Python-Style OO in Javascript.

Now, I don't think I am the first one who thought of this. In fact, prototype.js does something like this for their method extensions to DOM objects. The main idea is this: if you specify self as the first argument to a method explicitly, you will be able to use self inside of nested closures within the method without having to create a self variable manually, i.e.:

var self = this

or doing something like Function.prototype.bind, or pass the context explicitly around like the Array methods forEach, map, every, etc.

This is but a small proof-of-concept. The result is you can write a class like this:

var Man = Class(Object)({
  __init__: function(self, name){
    self.name = name
  },
  greeting: function(self, other){
    setTimeout(function(){
      self.say("Hello, " + other.name + ", my name is " + self.name)
    }, 100)
  },
  say: function(self, msg){
    sys.puts(msg)
  }
})

Take it for a spin:

var dan = new Man('Dan')
var john = new Man('John')
dan.greeting(john)
john.say('How do?')

Output:

How do?
Hello, John, my name is Dan

The implementation of Class looks like this:

function toArray(args){
  var ret = []
  for (var i = 0; i < args.length; i++)
    ret.push(args[i])
  return ret
}

function Class(parent){
  function bind(func, obj){
    var ret = function(){
      var args = toArray(arguments)
      args.splice(0, 0, obj)
      return func.apply(undefined, args)
    }
    return ret
  }
  
  return function(attrs){
    return function(){
      for (var name in attrs){
        var value = attrs[name]
        if (typeof(value) == 'function'){
          this[name] = bind(value, this)
          this[name].name = name
        }else{
          this[name] = value
        }
      }
      this.__init__.apply(this, arguments)
    }
  }
}

Full source can be found here. I ran it in node. This could be an interesting approach to avoiding "this-hell".

One-Liner WebServer with Python

toby ho — Mon, 26 Apr 2010 10:43:33 -0500

Turns out, even better than my HTTP Server in 5 Lines With Webrick is this one-liner:

python -m SimpleHTTPServer

This will serve on port 8000 by default, but you can add the port number as the last argument to override. Nice! Credits go to this article.

Get Argumentative with Javascript

toby ho — Mon, 29 Jun 2009 23:56:28 -0500

When I looked at the Google Maps API for Javascript, I couldn't help but notice that all the functions in the API Reference look kinda Pythonic. Functions call be call with a positional argument list like normal, i.e.:

new GMap2(mynode, myopts)

or by name with an object literal:

new GMap2({node: mynode, opts: myopts})

Moreover, arguments can be optional, and they are denoted in the doc with a ? at the end. Finally, the type of each argument is specified.

Here is an example of their API:

GMap2(container:Node, opts?:GMapOptions)

I thought: How cool is this!!?? I want this!! But, as the Maps API is proprietary, I couldn't get hold of their source. So, it was time for a little hacking...

My immediate goals were: argument validation, named argument passing, and optional arguments. Now I have a prototype with these three things working.

Argument Validation

Argument validation in my terms means checking the input arguments to a function when it is called to see if they are valid. The most basic of these checks is whether the number of arguments is correct. Example, we start with a simple add function:

function add(one, other){

  return one + other;

Then we enhance it by wrapping in with the $f function:

add = $f(add);

The new enhanced add function now will require the argument list to match up with what is expected:

> add(1,1)
  2
> add(1)
  Error: Argument 'other' of function add(one, other) was not specified.
> add(1,2,3)
  Error: function add(one, other) expected 2 arguments but got 3: (1, 2, 3).

Named Argument Passing

Named argument passing is something that Python programmers enjoy, but in Javascript you can simulate it using map literals. For example, given the add function defined above, you can now also write:

> add({one: 1, other: 2});

The order does not matter because it is a map, so the above is equivalent to:

> add({other: 2, one: 1});

You can also mix positional and named arguments just like in Python:

> add(1, {other: 2});

Optional Arguments

Optional arguments is another great Python feature. It is really the feature that makes named argument passing worthwhile. In Python we have a nice syntax to specify the default value for an optional argument:

def f(x=0):

  return x * 2

In Javascript, not so lucky. I had to resort to this:

f = $f(

  {x: 0},

  function f(x){

    return x * 2;

Not so bad? Maybe? I am trying to make it look like a decorator/annotation. So, with this code, you can do:

> f()

Just what you'd expect.

The combination of named argument passing and optional arguments enable very concise code in some situations. Example, let's say you have a function that generates an html input element given a bunch of parameters:

function input(type, name, value, classes){
  return '<input \
    type="' + type + '" \
    name="' + name + '" \
    value="' + value + '" \
    class="' + classes.join(' ') + '">';
}

In this case, type and name are required. Value is required by the spec but we can just default it to ''. Classes is optional and we'll just default it to [] to avoid a check for null.

So the code to do that is:

input = $f({value: '', classes: []}, input)

And now you call call the function in these variety of ways:

> input('text', 'age')
  <input     type="text"     name="age"     value=""     class="">
> input({type: 'text', name: 'age'})
  <input     type="text"     name="age"     value=""     class="">
> input({type: 'text', name: 'age', classes:['text', 'age']})
  <input     type="text"     name="age"     value=""     class="text age">

Nice!

The code for this prototype is as usual on github. The next on my todo list is to implement variable length argument list and extra keyword argument lists. So stay tuned.

Prototype Inheritence in Python

toby ho — Sat, 23 May 2009 13:04:39 -0500

One of Toby's favorite pastimes is to take concepts from one language and realize it in another. In this episode: Toby implements Javascript-style prototype inheritence in Python.

One thing that is super cool about Javascript is the fact that objects are just maps. Not only can you add attributes dynamically at any point, you can also add methods dynamically. In Python, you can add methods dynamically, but normally you'd have to add it into the class. But there are cases when you don't want to bother making a class. This inspired me to see how far I can go in making Python behave more like Javascript.

Introducing prototype.py

prototype.py lets you write code in Python with Javascript-style prototype inheritence semantics. If you are not familiar with prototype inheritence, just read on for now. I will link to some resources at the end. Now, let's see how to use this bad boy. First you import the module:

>>> from prototype import *

To create a constructor(we don't really have classes anymore), you write a function with the @constructor decorator:

>>> @constructor
... def Person(this, first, last):
...   this.firstName = first
...   this.lastName = last
...
>>> Person
<constructor 'Person'>

I am going to use this rather than self and camelCase rather than under_scores for prototype-style code, because, well...Dorothy, we are not in Kansas anymore.

Now you can do:

>>> bird = Person('Charlie', 'Parker')
>>> bird.firstName
'Charlie'
>>> bird.lastName
'Parker'

You can add attributes to the object just like in normal Python. But unlike in normal Python, which would raise an AttributeError when trying to access non-existent attributes, in prototype-land it merely returns None:

>>> print bird.age

None

You can dynamically add a method to the instance just by tagging on a function:

>>> def sing(this):
...   print '%s sings!!' % this.lastName
...
>>> bird.sing = sing
>>> bird.sing()
Parker sings!!

This affects only the bird instance. If you want the method to be added to all instances of Person however, you can add it to the prototype of Person.

>>> Person.prototype.sing = sing

>>> monk = Person('Thelonious', 'Monk')

>>> monk.sing()

Monk sings!!

This works because Person.prototype is the prototype of the monk instance. In code, this means:

>>> monk.__proto__ == Person.prototype

True

When the sing attribute is not found on the monk instance itself, it will follow the __proto__ reference and look it up in its prototype, which is also referred to as its parent. We can manipulate the parent link:

>>> monkJr = Person('T.S.', 'Monk')

>>> monkJr.__proto__ = monk

so that now monkJr inherits all of monk's attributes:

>>> monk.hair = 'black and curly'

>>> monkJr.hair

'black and curly'

The following are some other properties demonstrating the prototype inheritence model:

>>> assert monkJr.constructor == monk.constructor == Person

>>> assert Object.prototype.constructor == Object

>>> assert Person.prototype.constructor == Person

>>> assert Person.prototype.__proto__ == Object.prototype

If this seems confusing, remember that in prototype-land, there are two kinds of things: constructors and instances. The prototype of a constructor is nothing more than an instance of the type that the constructor represents. A new instance returned from calling a constructor will have its parent set to the prototype of the constructor.

Things You Can't Do in Javascript, i.e. the 1+1>2 Effect

Python is a more powerful and flexible language than Javascript, so, why am I dumbbing it down to Javascript's level? To show that I am not trying to do that at all, let me point out that there are at least a couple of really cool things you can do with prototype.py that you can't with Javascript, simply due to the fact that it is in Python.

The first thing is properties. With prototype.py, you can add properties to objects like so:

>>> def getName(this):
...   return '%s %s' % (this.firstName, this.lastName)
...
>>> Person.prototype.name = property(getName)
>>> bird.name
'Charlie Parker'

You can also specify setters and deleters in the way you'd expect:

>>> def setName(this, name):
...   first, last = name.split(' ')
...   this.firstName = first
...   this.lastName = last
...
>>> def deleteName(this):
...   del this.firstName
...   del this.lastName
...
>>> Person.prototype.name = property(getName, setName, deleteName)
>>> bird.name = 'Dizzy Gillespie'
>>> bird.name
'Dizzy Gillespie'
>>> del bird.name
>>> bird.name
'None None'

The second thing is named parameters, keyword parameters and optional parameters. Let's just do an example with keyword parameters. Let's say I just wanted a way to easily create ad-hoc objects as key-value pairs, I could write:

>>> @constructor

... def Data(this, **kwargs):
...   for key in kwargs.keys():
...     setattr(this, key, kwargs[key])
...

Which lets me write:

>>> project = Data(project='prototype.py', language='python')

But, I could also define methods and properties in this way:

>>> file = Data(fileName='prototype.py', fileExt=property(getExt),

                    read=read, write=write)

Sweet!

A Note About the Implementation

The implementation of prototype.py is only about 60 lines of Python at time of writing, would have gone down to 40 without property support. The code can be found here.

A big discovery that enabled me to do this was the new module. It allowed me to take a function and make it into an instance method by binding it to an object:

method = new.instancemethod(function, object)

Another note is that I made the design decision that for methods, I chose to store the unbound function rather than the bound method in the __dict__ of the object. I would then bind the function on the fly when it's asked for. This made it very easily to inherit methods because you don't have to worry that the method is really bound to the parent rather than the instance in question.

Null in 10 Languages

toby ho — Mon, 11 May 2009 13:39:21 -0500

Java, Javascript, C#: null
Ruby, Smalltalk, Lisp, OCaml: nil
Lisp: ()
Python: None
Haskell: Nothing
C: 0

Parameterizing Your Tests

toby ho — Wed, 11 Mar 2009 23:01:06 -0500

I use Selenium at work to write browser tests. I use the Python bindings with Selenium Remote Control to drive the tests. Now, once you have written a test suite, it is not unreasonable to want to run the same set of tests over different browsers. Now that the browser space is getting interesting again, you'd better test your app on 5 or 6 browsers. So how do I write my tests once, and run them on different browsers? In the Python unittest framework, tests are written as classes that extend unittest.TestCase. So, to parameterize them, you can can subclass the test dynamically and set the browser attribute onto it:

import unittest

class TestPages(unittest.TestCase):
    def testPage(self):
        print("testing page on %s" % self.browser)

TestPagesOnFirefox = type('TestPagesOnFirefox', 
                                 (TestPages,), dict(browser='firefox'))

if __name__ == '__main__':
    unittest.main()

So, we are subclassing TestPages calling it TestPagesOnFirefox and at the same time setting its browser attribute to 'firefox'.

We run it and get this error:

AttributeError: 'TestPages' object has no attribute 'browser'

This is because TestPages does not have the browser property defined. What do we do? Let's erase it:

del TestPages

After that it runs okay and we get the output we want:

testing page on firefox
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

So we can generalize that and expand all the browsers you want to. We write an expand_browsers function like so:

def expand_browsers(gls, browsers=['firefox', 'ie6', 'ie7', 'safari', 'chrome', 'opera']):
    original_test_classes = filter(
        lambda o: isinstance(o, type) and issubclass(o, unittest.TestCase), 
        gls.values())
    
    for cls in original_test_classes:
        for browser in browsers:
            new_class = type('%sOn%s' % (cls.__name__, browser), (cls,), dict(browser=browser))
            gls[new_class.__name__] = new_class
        del gls[cls.__name__]

After you declare all you tests you call the function like so:

expand_browsers(globals())

This goes through the namespace of your module and for each class that is a subclass of unittest.TestCase(You can choose a different subclass as marker here if you want), it subclasses it and specifies the browser property in it. After that, it erases the original testcase class so that it can't be found, like we did above.

Final complete example:

import unittest

class TestPages(unittest.TestCase):
    def testPage(self):
        print("testing page on %s" % self.browser)

class TestMorePages(unittest.TestCase):
    def testPageTwo(self):
        print("testing page two on %s" % self.browser)

def expand_browsers(gls, browsers=['firefox', 'ie6', 'ie7', 'safari', 'chrome', 'opera']):
    original_test_classes = filter(
        lambda o: isinstance(o, type) and issubclass(o, unittest.TestCase), 
        gls.values())
    
    for cls in original_test_classes:
        for browser in browsers:
            new_class = type('%sOn%s' % (cls.__name__, browser), (cls,), dict(browser=browser))
            gls[new_class.__name__] = new_class
        del gls[cls.__name__]

expand_browsers(globals())

if __name__ == '__main__':
    unittest.main()

Output:

.testing page two on firefox
.testing page two on ie6
.testing page two on ie7
.testing page two on opera
.testing page two on safari
.testing page on chrome
.testing page on firefox
.testing page on ie6
.testing page on ie7
.testing page on opera
.testing page on safari
.
----------------------------------------------------------------------
Ran 12 tests in 0.000s

OK

Code examples also on github.

goodday dot py

toby ho — Thu, 22 Jan 2009 18:09:47 -0600

Looking at rails and the datejs library, I can't help but feel bummed that Python doesn't have an expressive date library like that. So I started one. I've put up my code on google code.

Auto-mixin in Python

toby ho — Sun, 18 Jan 2009 00:03:16 -0600

Python has multiple inheritence - a feature that's really handy because it allows the programing idiom called mixins - where you write a a bunch of methods on a "mixin" class and then later on attaching all of those methods onto another class simply by mixin-it-in. In Python, the process of mixin-it-in is simply to add it to the parent list of the class:

class MyObject(MyParent, MyMixin):

...

In Ruby, you can automatically mix in a mixin programmatically because the mix-it-in is done within the class definition, and because of its open classes. This is how the rails helpers are automatically found in a directory and mixed into the controllers for example.

How would you do this in Python? Let's say we simplify the problem to this: For a given Controller subclass named ProductController, for example, if there exists a helper class by naming convention: ProductControllerHelper, then we mix it in. Here's my solution:

class Meta(type):
    def __new__(cls, name, bases, dct):
        helper_mixin = globals().get('%sHelper' % name)
        if helper_mixin:
            bases = list(bases)
            bases.append(helper_mixin)
            return type.__new__(cls, name, tuple(bases), dct)
        else:
            return type.__new__(cls, name, bases, dct)
        
class Controller(object):
    __metaclass__ = Meta
        
class ProductControllerHelper(object):
    def method1(self):
        print "method1 invoked"
        
class ProductController(Controller):
    def index(self):
        self.method1()
        
        
if __name__ == '__main__':
    ProductController().index()

Output:

method1 invoked

It worked!

But! We are not done. What if what you want to mix in depends on how you configure the class inside the class definition? In my case, I wanted to mix in a bunch of classes when I write a DSL-like declaration like this:

class MyTestCase(TestCase):
    all = fixture(SeleniumRCServer, BrowserSession, DBData, Login)
    each = fixture(AddDelivery)

...

This is for a testing framework I am working on. I have a test case, and I want to specify its test context(fixtures) in the manner shown. Each object in the fixture(..) definition is a mixin. So I want to mix them all into MyTestCase.

This case is harder than the previous case because when __new__ is invoked, the class definition hasn't been processed yet, and therefore you won't have access to the class attributes all and each. The hack I came up with is this:

class TestCaseMetaClass(type):
    def __init__(cls, name, bases, dct):
        if len(bases) == 1 and bases[0] != unittest.TestCase:
            bases = list(bases)
            bases.extend(cls.all)
            bases.extend(cls.each)
            cls.__real__ = type(name, tuple(bases), dct)
        else:
            type.__init__(name, bases, dct)
        
    def __call__(cls, *params, **kws):
        if hasattr(cls, '__real__'):
            return cls.__real__(*params, **kws)
        else:
            return type.__call__(cls, *params, **kws)
            
class TestCase(unittest.TestCase):
    __metaclass__ = TestCaseMetaClass

Basically, I first override __init__ of the metaclass(rather than __new__) in order to record what was declared in all and each, and create a new class on the fly mixing in all the mixins defined in the fixture(..) definitions. We store that class in an attribute __real__ attached to the class. Then we override __call__ for the metaclass to return an instance of the class held in the __real__ attribute instead of the actual class. Oh yes, this is really ugly, but it worked, at least for what I was doing. If you can write to a classes' __bases__ attribute(which defines the parents of the class), then this would be much easier, but I haven't figured out how to do it if it can be done at all. But because of this limitation, it looks unlikely you can do something like Ruby's mixology in Python.

Update: the better solution to the second part is found:

class Meta2(type):
    def __new__(cls, name, bases, dct):
        mixins = []
        all = dct.get('all')
        if all:
            mixins.extend(all)
        each = dct.get('each')
        if each:
            mixins.extend(each)
        bases = list(bases)
        bases.extend(mixins)
        return type.__new__(cls, name, tuple(bases), dct)
        
class TestCase(object):
    __metaclass__ = Meta2
    
class Fixture1(object):
    def method2(self):
        print "method2 invoked"
    
class Fixture2(object):
    def method3(self):
        print "method3 invoked"
        
class BlahBlahTest(TestCase):
    all = [Fixture1]
    each = [Fixture2]
    def blah_test(self):
        self.method2()
        self.method3()

Posts about Python

Book Review: Python Testing Cookbook

The Good

The Bad

Summing Up

Book Review: Python 3 Web Development - Beginners Guide

Chapter 1

Chapter 2

The Rest of the Chapters

Conclusion

Python Book Reviews Forthcoming

Smart Parameter Checks in Python

Fun with Parameters

Proof-of-Concept

Working in Python-Mock

Python-Style OO in Javascript

One-Liner WebServer with Python

Get Argumentative with Javascript

Prototype Inheritence in Python

Introducing prototype.py

Things You Can't Do in Javascript, i.e. the 1+1>2 Effect

A Note About the Implementation

Further Reading About Prototype Inheritence

Null in 10 Languages

Parameterizing Your Tests

goodday dot py

Auto-mixin in Python