LPTHW - Exercise 52

This is the last exercise in the LPTHW book. In this exercise we will create a web based game engine for the Gothon game (the one we created in exercise 42), using the structure we created in exercise 47, along with tests and everything.

The first thing I did was to copy the entire contents of ex47 to ex52. Then I renamed game.py to map.py and made a corresponding change for the test case also. Then I ran 'nosetests' and everything seems to be fine at this stage.

In exercise 42, each room was a function in the Room class. But now in exercise 52, we will make each Room an instance of the Room class. I coded the class map.py (containing all the rooms) as shown in the book. Next, I am going to copy the map_tests.py file as is in the tests directory.

After copying the code in map.py, I created another Python module for messages, called messages.py. This module will contain the initial text for all the rooms, as well as the transition text, which is displayed to the user when they transition from one room to another.

Next, I refactored map_tests.py to test all the rooms, their initial text, and transitions.

The book then explains how lpthw.web maintains sessions. I understand how sessions are managed, but the session variable which seems global to the module confused me, because it makes me think that only one instance of that variable would exist.

I copied the apps.py file in bin, and also fixed a couple of bugs.

I also added two HTML templates - layout.html, show_room.html, and game_lost.html

Part of the code is embedded below:

LPTHW - Exercise 51

In this exercise, we learn how to deal with form input and a bit about testing web apps.

The first thing I did was to change app.py and refactor it to handle web input. We will handle simple input as GET input parameters to start with.

Here is the new app.py file:



Now if you notice, in this file we use the line

form = web.input(name="Nobody")

to handle the input. If the input contains a 'name' parameter, then we will use it, else it will default to "Nobody", since we have given a default value as an argument to the function call.

Getting the values as url parameters is not a good idea:

This is a good beginning, but we should really be getting the values in a form and not as command line parameters. For this we will need to add some HTML and a method in the Index class to handle POST data (since this is the default method for sending form data).

I made a few changes to app.py, index.html, and added a new file hello_form.html All the code is embedded below:



Don't repeat boilerplate code:

It's very good that we can now handle form data. However, the observant programmer must have noticed that both index.html, and hello_form.html have common boilerplate code. It would be good if we can remove the repetition. Well, we can, if we use templates.


All the code which uses templates is embedded below:

LPTHW - Exercise 50

In this exercise we will make a web application from the Gothons game, which we made in exercise 46. To simplify the process of making a web application, we need a we need a web framework. For this exercise we will use lpthw.web, which is the same as the webpy framework.

I installed the web framework thus
pip install lpthw.web

Then I created a project for the web application by creating a directory in my projects directory:
ex50
/bin
app.py
/docs
/gothonweb
__init__.py
/templates
__init__.py
/tests

I just copied the code provided in LPTHW in app.py

I ran the webserver with 'python bin/app.py' and successfully loaded the url http://localhost:8080

However, I realized that lpthw.web was not installed in my virtualenv as I would have expected it to be. It was actually installed in /usr/local/lib/python2.6/dist-packages/ This seems strange and incorrect to me. I am not quite sure what went wrong, so I asked a question on StackOverflow.

The code for this exercise is embedded below:

LPTHW - Exercise 49

In the previous exercise, we had created a scanner, which would take a line of words as input and return to us a list of tuples which gave us the type of each word.

In this exercise, we try and add some intelligence to our game, and identify sentence parts in the user input.

This is a bit of an over-simplification, but we will consider a sentence to consist of the following structure: subject verb object

If our sentence contains words from our lexicon and is of the above form, then we will be able to parse the sentence and take an action in the game based on it. We ignore stop words, and also allow for arbitrary upper/lower case. This gives the player a decent amount of freedom in creating their commands. So for example they could enter "eat bear", or they could also enter "Eat the bear" and both the inputs will be accepted as valid by the sentence parser.

For this exercise I copied the code from ex48 because we still need the lexicon and lexicon_tests files. In addition I added the files sentence.py and sentence_tests.py

The entire code is embedded below.

LPTHW - Exercise 48

In this exercise, we created an intelligent input scanner, which we can use in our games. This scanner takes a line of input, and returns a list of tuples, each containg the 'type of word' and the word itself.

We were given the unit tests (lexicon_tests.py), and were supposed to write the actual code (lexicon.py) to fulfill the tests. This exercise was a lot of fun.

The test suite and code is embedded below:

LPTHW - Exercise 47

In this exercise we create a very simple class for a game, and then create unit tests for it.

Since, I have already done much programming (albeit in Java), I am familiar with the concept of unit testing, and why it is important.

Python seems to have something called 'nose' which is a test harness similar to JUnit for Java. Here is the production and test code modules.



In our project, we have a directory called tests, which holds all our tests. The test module name is 'actualmodule_test.py', where 'actualmodule' is the name of the module which is being tested.

The test script has setup and teardown functions, but when I ran the tests with nosetests, these functions were not run. I need to figure out why.

Creating and installing a script in my distribution module

In the previous blog post, I explained how to create and distribute a package distribution. If the package were a library, then most likely this is where it would end. However, since I have created something which will be used as a command line desktop application, it would be wonderful if I could bundle a script which the user can invoke from the command line.

First I made a shell script, which would invoke a Python module, however I ran into an issue where the interpreter could not locate the Python module. I think it should have since the package has already been installed with distutils. I need to spend some time understanding how the interpreter locates modules.

In the spirit of moving ahead, I decided to create a Python script and make it executable instead. Once I created the script, I again ran setup.py, which caused this script to be copied in the 'bin' directory of my ENV. Here is the simple Python script I created.