I have been reading about Scala and learning improved coding practices along the way. In additional to wishing that I could use such a cool language at work, I’ve also been trying to apply what I’m learning towards improving my Python code. One of these “scalaisms” is the encouragement of method chaining. I think I must have considered method chaining a bit too smelly to really give it a shot. Once I saw some examples in a couple of Scala books, though, my mind opened up to the idea. Thinking about method chaining in Python while reading about iterators and generators (reading about functional concepts in Python) led me to consider applying both concepts. I came up with the idea of chaining iterators as a way to iterate over and filter large lists. A nice thing about iterators is that they are lazy. They only return their contents one item at a time. I wanted to chain iterators that could be dynamically plugged together to filter the contents of a list lazily. The rest of this blog post will be about my proof-of-concept code.
First, I needed something to iterate over. I decided to work with objects that represented pets in a pet store (the simplest idea I could come up with).
class Pet(object):
@staticmethod
def from_list(args_list):
kwargs = dict()
type_str = args_list[0]
if type_str == "Dog":
pet_clss = Dog
elif type_str == "Cat":
pet_clss = Cat
else:
raise ValueError("Unknown Pet type '%s'" % type_str)
return pet_clss(**dict([[args_list[x], args_list[x+1]] for x in range(1, len(args_list)-1, 2)]))
def __init__(self, **kwargs):
self.name = kwargs['name']
self.breed = kwargs['breed']
self.owner = kwargs.get('owner', None)
self.color = kwargs['color']
def was_sold(self):
if self.owner is not None:
return True
else:
return False
class Cat(Pet):
def __init__(self, **kwargs):
Pet.__init__(self, **kwargs)
self.meows = kwargs.get("meows", True)
class Dog(Pet):
def __init__(self, **kwargs):
Pet.__init__(self, **kwargs)
self.barks = kwargs.get("barks", True)
I wanted to be able to load data from a CSV file, hence the from_list() constructor. Here is a parent class called Pet which is inherited by Cat and Dog.
The rest of the code is based on FilterablePetStore. This is an abstract class that I used to test two different approaches to implementing a filterable PetStore class.
class FilterablePetStore(object):
def __iter__(self):
raise NotImplementedError()
def filter(self, filter_func):
return PetStoreView(self, filter_func)
def was_sold(self):
return self.filter(lambda pet: pet.was_sold())
def is_type(self, test_type):
return self.filter(lambda pet: isinstance(pet, test_type))
def is_color(self, color):
return self.filter(lambda pet: pet.color.upper() == color.upper())
def is_tabby(self):
return self.filter(lambda pet: pet.color.upper().endswith("TABBY"))
def as_list(self):
return [pet for pet in self]
FilterablePetStore just contains some ideas of how a pet store might want to filter their list of pets. Notice also that filter() method takes a function as its argument, and all of the other methods simple reuse the filter() method by supplying a function.
First I’ll show the simple way to implement method chaining in Python. This does not use iterators. Each method in the chain returns a new object which contains its own list of pets. (I actually coded this one second, hence the ‘2’ in the name).
class PetStore2(FilterablePetStore):
def __init__(self, list_of_pets):
self.pets = list_of_pets
def __iter__(self):
return iter(self.pets)
def filter(self, filter_func):
return PetStore2(filter(filter_func, self.pets))
def as_list(self):
return self.pets
This should be pretty straight forward. The filter() method returns a new PetStore2 instance with a new (possibly smaller) list of pets. Additional methods are inherited from FilterablePetStore.
The more interesting implementation uses iterators. The goal of this code was to lazily evaluate each call to next() (see iterators) all the way through the chain of methods.
class PetStore(FilterablePetStore):
def __init__(self, list_of_pets):
self.pets = list_of_pets
def __getitem__(self, index):
assert isinstance(index, int), "Index must be an integer"
return self.pets[index]
def __iter__(self):
return PetStoreView(self, lambda pet: True)
class PetStoreView(FilterablePetStore):
def __init__(self, pets, filter_func):
self._pets = pets
self._location = 0
self._filter_function = filter_func
def __iter__(self):
return self
def next(self):
try:
try:
next_item = self._pets.next()
except AttributeError:
next_item = self._pets[self._location]
self._location += 1
except IndexError:
raise StopIteration()
if self._filter_function(next_item):
return next_item
else:
return self.next()
Here the iterator is implemented by the PetStoreView class. A potential drawback of this approach is that you don’t end up with a PetStore object, but since the goal was to create an iterator chain, this isn’t a big deal. Each element is passed down the filter chain and, if it passes all of the filters, is iterated over. Each element waits until the next iteration before being filtered; there are no intermediary lists.
So what is my conclusion? That will have to come in another post!
Here is the code for anyone who wants to play with it.
For as long as I’ve been doing DXL development, I’ve desired ways to interface DOORS with languages besides DXL. This desire was rooted in my prior experience with writing automation scripts for Rational ClearQuest. Though quirky, I had found CQ very easy to automate using COM. Rational DOORS, on the other hand (owing most likely to its Telelogic origins) provides very little in the way of COM automation or any other interface besides DXL for automation. It is my opinion that this design decision is a legacy form of lock-in for the DXL language (and associated consulting charges). The COM automation for DOORS is limited to launching DOORS, sending it DXL code, hoping that the code succeeds, and then possibly receiving some string output. (Note that the opposite is true when DOORS is the client; automating other COM components is reliable, if tedious).
In addition to this simple COM server capability, DOORS also provides a similar socket server. It still requires automating DOORS using a fair amount of DXL code. If we accept that we are going to have to muck around with DXL code, possibly dedicating it towards providing an API that is driven by code written in another language over the socket, we can still manage to get a lot of work done. The usage of such a system seemed obscure to me at first (the documentation didn’t help a ton), but it was actually pretty easy to create a simple socket server in DXL and a socket client in Python. This is is where Python really shines.
Here is the DXL socket server code. This code can be executed in the DXL interactive editor. It will lock up the client GUI while the code loops waiting for connections. Connecting clients can then send arbitrary DXL code or the keywords “quit_” (to disconnect) or “shutdown_” (to shutdown the DXL socket server).
Here is the Python socket client code. First, to shutdown the DXL socket server, run the client script like “python IPC_Client.py —shutdown”. This will unblock the DOORS GUI. Otherwise, run the script without any arguments and the three print_* functions will send DXL code to the socket server and then print the returned results.