5.20 Implementing a Collection

Credit: Skip Montanaro

5.20.1 Problem

You have a bunch of objects and want to make method calls and implement attribute lookups that operate on each object in the bunch.

5.20.2 Solution

I'm used to thinking of a proxy that forwards attribute lookups to a bunch of objects as a collection. Here's how to make one in Python 2.2:

class Collection(list):
    def get(self, attr):
        """ Return a collection of same-named attributes from our items. """
        return Collection([getattr(x, attr) for x in self if hasattr(x, attr)])
    def call(self, attr, *args, **kwds):
        """ Return the result of calling 'attr' for each of our elements. """
        attrs = self.get(attr)
        return Collection([x(*args, **kwds) for x in attrs if callable(x)])

If you need to be portable to Python 2.0 or 2.1, you can get a similar effect by subclassing UserList.UserList instead of list (this means you have to import UserList first).

Using this recipe is fairly simple:

>>> import sys
>>> streams = Collection([sys.stdout, sys.stderr, sys.stdin])
>>> streams.call('fileno')
[1, 2, 0]
>>> streams.get('name')
['<stdout>', '<stderr>', '<stdin>']

5.20.3 Discussion

In some object-oriented environments, such Collection classes are heavily used. This recipe implements a Python class that defines methods named get (for retrieving attribute values) and call (for calling attributes).

In this recipe's class, it's not an error to try to fetch attributes or call methods that not all items in the collection implement. The resulting collection just skips any unsuitable item, so the length of results (which are different from those of the map built-in function) may be different from the length of the collection. You can easily change this behavior in a couple of different ways. For example, you can remove the hasattr check to make it an error to try to fetch an attribute unless all items have it. Or you could add a third argument to getattr, such as None or a null object (see Recipe 5.24), to stand in for missing results.

One of the interesting aspects of this recipe is that it highlights how Python makes it possible but not necessary to make classes for encapsulating fairly sophisticated behavior such as method and attribute proxying. Doing this is valuable in two respects. First, centralizing the code reduces the risk of errors creeping in duplicate copies throughout a code base. Second, naming the behavior (in this case based on prior art from another language) enriches the programmer's lexicon, thereby making it more likely that the concept will be reused in the future.

5.20.4 See Also

Recipe 5.21 and Recipe 5.24.