Credit: Skip Montanaro
You have a bunch of objects and want to make method calls and implement attribute lookups that operate on each object in the bunch.
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>']
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.
Recipe 5.21 and Recipe 5.24.