Oz

I also forgot to point out how tests are often the best documentation for functions. 

+1 For that!

If I see a python module foo.py and test_foo.py I know I have a good project at hand. I will than open vim in split mode and read both in parallel!

Anytime I see anything documented in Word or PDFs I worry(and cry). 

100% Correct!

As a rule don't comment your code. 

This is a matter of taste. I like having sparse comment explaining briefly what each function or class does. This is also the way to produce beautiful documentation using tools like sphinx.
But in a way you wrote down the essence of what tools like sphinx encourage you to do.

The option --short is not available on git version 1.7.1 (which is the default for many RHEL based systems outhere (CentOS 6 etc...).

SWEET!

@klang, awesome!

you mean as user root ?
Could be problematic, because most of the time in environment the HOME partition is mounted with rootsquash. Hence as root I don't have access to my own vimrc in /home/oz/.vimrc

With all three arguments you are right.
I would always opt for stdlib. However, with packages I didn't necessarily mean Python packages.
The idea was to write a code that should work on similar cases. Not always on classes.
Imagine you wrote your own package manager (for Distro X) then you will need something.
Yep, you are right dependencies are forgotten. This is the case with RPMs or DEBs. Package x gets dependency y and the maintainer forgets to add it.
This code was not meant to conform to standard.
It was slightly altered from a project I worked for which something similar to package management. In order not complicate stuff and make it clear for fellow programmers, I chose to talk about classes. It was a wrong choice.
Never the less, I find the discussion, interesting and I learned already a lot just from the discussion with you. Therefore thank you for the discussion and extended comments.

Hi Demian,
First of all, I didn't know about ìnspect.mro. Thanks for that one. Second, yep, my idea was that these class can represent anything (e.g. rules, package dependencies) so they don't necessarily inherit like Python objects, but the have a dependencies. Kind of like decencies solving in packages. So, it was done for the exercise, and I wanted to share my experience and see if I get some feedback.

Hi Demian,
You are right, filter is also usable here:

filter(lambda x: isinstance(x, DjangoProject.itemModel.SomeProperty), result)

However, filter will return the list result itself, clean of unwanted items. Which for me was not possible. I wanted to have 'all or nothing', that is why I used the combination of all and map.