Conversations with Computers or: How I Learned to Stop Worrying and Love the Generator
One of the features I’d put off developing for Automaton is being able to hold
“conversations” with a service. Because services were defined as functions
they took in your input and returned output back to you. If you didn’t
provide enough information, the service terminated with an
UnsuccessfulExecution exception and you had to try again. From the beginning.
If the input given was
Give me directions to Canada and the service could
not determine your current location, it would respond with something like
Cannot determine your current location. Please try again. To actually get
directions, you would have to duplicate your request with the missing data
Give me directions from North Dakota to Canada.
It would be 1000x better if instead the service said “I could not determine your location, where do you want to start from?”, letting me reply with “North Dakota” to get my directions. Unfortunately, this is a networked application - the client I send my requests to talks to the server holding this conversation with me. How do I manage a conversation when the connection can drop at any moment? Further, the “entry point” that my client talks to is the exact same that another simultaneous client is using - one of the pitfalls of the non-threadsafe Thrift server I’m developing with.
For a moment, I considered using classes for the services instead of functions so I could take advantage of state, but the Plugin that hosts services is already a class and I didn’t want tons of nested classes. Plus, classes that conform to whatever conversation interface I’d cook up would add a lot of boilerplate for plugin developers, especially if they didn’t want to take advantage of this new feature. Luckily, I stumbled upon this beautiful piece of work in the Python PEPs. If you’re not familiar, PEPs are very well-written proposals for new features to Python. Most, if not all of the new features Python gains are part of one of these specifications. If you’re interested in finding new cool ways to use Python, I highly recommend you browse the list for interesting titles. This PEP, in particular, proposes a syntax for turning Python functions (subroutines) into coroutines, subroutines with multiple entry points (as opposed to regular functions always beginning execution at the “top” of the function). This isn’t supposed to be an introduction to generators, so if you’re unfamiliar with them I will instead point you toward two great tutorials on them if you need to brush up - go ahead, this page won’t expire by the time you get back.
The key to conversations here is the ability to send values into generators
generator.send(value). Here’s an example:
def generator(): response = yield for count in range(5): response = yield "I got " + str(response) gen = generator() gen.next() # This starts the generator, now we can send values in. count = 0 try: while True: # Keep sending things until the generator gets tired print gen.send("something new " + str(count)) count = count + 1 except StopIteration: pass # The Generator is finished.
Now that we can give our services extra input while they’re in the middle of execution, let’s have an actual conversation with our computer:
def ask_about_weather(): response = (yield "Hey! How is the weather today?") if "cold" in response: yield "You should get a jacket." elif "warm" in response: response = yield "Isn't this weather awesome?" yield "Lets go outside." elif "hot" in response: yield "You should go to the beach!" else: yield "Keep on topic!" if __name__ == "__main__": try: gen = ask_about_weather() print gen.next() while True: inp = raw_input("> ") print gen.send(inp) except StopIteration: pass
Here we have a reversal of the intended conversation roles. When this script is
run, the computer asks “How is the weather?”. When you type something into
raw_input, it gets sent into the generator and the computer has different
responses depending on whether or not you typed the words “cold”, “hot”,
or “warm”. If you type “warm”, the computer asks a second question and you’re
given a second chance to respond. Run through a conversation and you’ll
notice that after the conversation comes to an end, control will wrap around
raw_input function one more time. You’re forced to hit enter and
then… the program ends. If the last
yield statement in each branch was
assigned to anything, that last raw_input value would be assigned, but
control passes to the end of the function (and an implied
return) and a
StopIteration exception is raised. All generators and iterators will raise
that exception when they finish but for loops silently catch them and exit
the loop so you may never have run into them before. Try it:
>>> i = iter(range(0)) >>> i.next() Traceback (most recent call last): File "<stdin>", line 1, in <module> StopIteration
I managed to find two solutions to this problem (though there are probably
more - Pythonistas are a creative bunch). The first is kind of a hack.
Generators are not allowed to pass anything to
return because immediately
after the StopIteration exception is thrown. Following that line of thought,
I replaced all
returns with manual throws of StopIteration, passing the
final message as an argument.
def ask_about_weather(): response = (yield "Hey! How is the weather today?") response = yield "Isn't this weather awesome?" raise StopIteration("Lets go outside.") if __name__ == "__main__": try: gen = ask_about_weather() print gen.next() while True: inp = raw_input("> ") print gen.send(inp) except StopIteration as err: print err
I’m not too keen on abusing
raise to return a value instead of the normal
process of automatically raising StopIteration when control leaves the
function, but it does work. My second solution takes advantage of the fact
that the next input to the computer is going to be a new conversation.
That “final” raw_input then becomes the new first input to the next
conversation. Below is an implementation similar to what I ended up using
in my program:
def directions(arg): arg = arg.split() to = None frm = None if "to" in arg: # Populate "to" and "frm" if given to = arg[arg.find("to") + 1] if "from" in arg: frm = arg[arg.find("from") + 1] if to is None: # Ask for more info if necessary to = yield "Where do you want to go to?" if frm is None: frm = yield "Where are you coming from?" # Present final output yield ("Why do you want to go to " + str(to) + " when you are already in " + str(frm) + "?") def weather(arg): arg = arg.split() location = None if "in" in arg: location = arg[arg.find("in") + 1] if location is None: location = yield "Where do you want weather for?" yield "The weather for %s is terrible." % str(location) if __name__ == "__main__": current_conversation = None while True: inp = raw_input("> ") if current_conversation is not None: try: print current_conversation.send(inp) except StopIteration: current_conversation = None # Note no elif - when StopIteration happens, we # fall through and start a new conversation with inp if current_conversation is None: if "directions" in inp: # Choose which service to use current_conversation = directions(inp) elif "weather" in inp: current_conversation = weather(inp) else: break print current_conversation.next() # Go to first "yield" statement
weather are pretty much the same thing for differing
numbers of “arguments”. If there is missing information, one of the
yield statements is executed, otherwise the final output is
printed. After the final output is printed, the next input is used to start
an entirely new conversation.
> I want the weather. Where do you want weather for? > Kansas The weather for Kansas is terrible. > Give me directions to Canada. Where are you coming from? > America Why do you want to go to Canada when you are already in America?
Of course, you’ll notice that you can only hold one conversation at a time.
That’s fine for this application, but what about in a networked environment
with multiple connected users? Make each user either register or create their
own ID, then send that along with every message, then change
current_conversation to a dictionary with the ID as the key. And that’s
it, you can now talk to computers! Watch out for weird stares.