Python - "in" gotcha

I'm currently working on the next release of Pynu. It will have some nice goodies I need for the file system project and better documentation. During development I happened to come upon an interesting "gotcha" in Python:



I would expect it to be False as I assumed it operates based on the identity of the object always. It will return True, however! So if you want to check does a list contain an empty list, use some other way (iterate items and check using "is" for instance).

Pynu - 0.1.0 released + Documentation tutorial

I just released the first version of Pynu, my node utility library for Python. It was developed based on the node module of Placidity. I converted the unit tests to doctest form and derived documentation directly based on that. In this post I will recap the steps I took and focus especially on the documentation part.

Placidity - Part 13, Analysis

This was my first experience in "Blog Driven Development" (BLDD?). I found following definition for it:

"Developers who are constantly thinking about the subject of their next blog post. Nearly every somewhat interesting line of code they write is extracted into a blog post."

I know the definition was written tongue in cheek but it has some truth in it. The main goal of the series was to document the development process of this particular project. Sometimes writing an application this way has felt a bit constraining. You just cannot go on and code whatever you want. :) It has forced me to keep the design digestable (or bloggable rather!).

I will take a look at individual parts of the series next and try to recap the main things covered in them. After that I will provide a list of lessons learned and finally I will construct a vision for future directions of the series.

Placidity - Part 12, Bounce

In the previous part of the series we finally managed to implement a proper way to quit from the application. As a side benefit scenario tester gained some meta functionality that may be used to restart the application and check its state (is it running or not?). In this part I will look into implementing a simple "bounce" command that just shows a simple bouncing ball in a window.

During an earlier experiment based on VPython I noticed that this is not quite a straightforward thing to do. The ball bounced just fine but the problem was that running the command blocked input. Probably the most straightforward way to handle the issue is to come up with a threaded solution. The idea is that there should be a repeating thread that handles redrawing the bouncing ball and a "master" thread that constantly polls for user input. As I have not used Python threading module earlier I had to do bit of research. I managed to find this post that got me going.

After tinkering around with the snippet in the post I managed to come up with a prototype. It's probably far from perfect but at least it seems to work just fine. Only major issue I have not managed to solve yet is the fact that if you close the window spawned by VPython it kills the whole application. There might be some workaround for this but I haven't managed to find it yet. Perhaps I should just take a look at VPython code. :P I also have to figure out how to spawn multiple VPython windows (handle with separate processes?).

I'm going to integrate the threading behavior in the actual application itself next. First I will replace the current input logic with threaded one. After that I will focus on implementing "bounce".

Agent Based Architecture in Python - Solving Marble Problem

I am currently reading Sherry Turkle's renowned The Second Self. It has provided some really nice food for thought. I was inspired by the concept of emergence she mentioned about.

Essentially the idea is that complex behavior may arise based on a set of simple rules. The particular case she described dealt with colored marbles on a table. Let's assume there are only black and white marbles. The question is are there more black marbles or vice versa?

If you can count and are able to compare numbers, it's easy enough to figure this out. It gets more problematic if you don't possess these skills. In this case you could try something simpler. A simple alternative is just to remove a pair of marbles having different colors till only marbles of one color are left on the table. Now it's just a matter of recognizing that color and stating the result.

Placidity - Part 11, Quit

In the previous part of the series I looked into implementing an Eliza command. This lead to the concepts of ellipsis (...) for scenario tester and "context" for commands. The idea of "context" was to provide means for commands to state that they want to listen to the user input explicitly. In a sense now it's possible to treat commands as programs of their own.

In this part I will look into implementing a proper command for "quit". Currently it's possible to quit the interpreter using "quit()" or ctrl-c. The problem is that "quit()" calls the native quit of Python (courtesy of Python command) and results in a nasty exception (ValueError: I/O operation on closed file).

I will solve this issue by writing a custom command that encapsulates the quit functionality and overrides this old, not desired behavior. I will also extend scenario tester to include a way to restart the application so that it's easy to verify that the application did indeed quit. Later on this feature could be used to test various other features such as persistency (it might be nice to be able to save a session and to be able to restore it).

The Greatest Game Ever? + Tomb, a webcomic

I just happened to come upon this little platformer a while ago. It's somewhat short (it takes around a minute or two to finish it) and well worth the time spent. Enjoy! :)

The author of the game has also created Tomb, a webcomic. It could be characterized as a weird mixture of Indiana Jones and Conan the Barbarian with some fantasy elements. If you are into that sort of thing, you might find it interesting. The comic is updated on weekly basis.

Placidity - Bounce Experiment (VPython)

It would be somewhat cool to be able to use Placidity as a visualization tool. I just took my first step towards this direction. I ported "bounce" example of VPython to a command.

The current version is not perfect as it blocks the user input. In other words after running it, quitting (ctrl-c) kills the whole application. This is due to the way I implemented window refresh.

I set up a thread that calls an update function on a predefined interval. I used Geoffrey Foster's RepeatTimer for this.

You can find the source of this experimental command here.

Apparently fixing the user input issue should not be too hard. I just need to set up a separate thread for polling user input instead of using raw_input as explained here. I will look into wrapping up "bounce" after the next part of my tutorial series in which I implement "quit" command to Placidity.

Placidity - Part 10, Eliza

I know I mentioned in the first part of this series that I am not going to write an Eliza bot.

The truth is that it would be a great feature to have, for lulz at least. And besides it's a great part of the history of computing. :) It also forces us to re-evaluate the design a bit as the bot has to be able to run as an entity of its own.

Instead of coming up with my own implementation of Eliza, I'm going to use an existing one I found here. Even though the code is old, it works after the references to a deprecated module, whrandom, are replaced with references to random.

I'm going to start out by writing a scenario describing how Eliza should work user interface wise. As it's not quite possible to predict what she will answer, I will define concept of ellipsis (...) which allows the input to be anything. After this I will look into encapsulating the bot in a command of its own and make the adjustments needed to the interpreter.

Placidity - Part 9, Application II

In the previous part of the series we managed to make the interactive interpreter to run as an application. It took quite a bit of tinkering but eventually we came up with something functional. I will look into improving the application in this part of the series.

My main goal in this part is to come up with system tests for the application. To accomplish this I will instrument the application properly and invent a simple scheme that may be used to mimic the user input and the expected output.

I will also convert the Python code evaluation part of the interpreter into a command and come up with a priority based scheme that allows me to define that the evaluation should happen only if nothing else matched before. This should help to get rid of the clash between command aliases and built-in Python functions.

Placidity - Source Available

As it's somewhat boring and ankward to build the tutorial project using copy/paste techniques I set up some repositories at GitHub. I split the source in two separate repos.

There's a repo for the code related to this blog. For now it contains just different parts of the Placidity tutorial. I also added links to each part of the tutorial series so it's easy to access the code in question.

I use the other repo for development of Placidity between blog posts and for possible development after I finish the series. In case you want to fork it or something, see GitHub documentation for instructions. As far as I understand that should be relatively easy, thanks to git. :)

Placidity - Part 8, Application I

So far we have implemented various bits and pieces needed by our interactive interpreter application. Finally it's time to integrate those parts and make it possible for the user to give it a go. First I'm going to implement it using old skool methodology (code first). After that I will restructure the code so that it's easier to test and sort out possible issues of which there are quite a few.

Placidity - Part 7, File System

Interestingly the previous part of the series led us to implement an abstraction for file system. In this part I will derive the needed tests based on mocks of the plugin loader and come up with an implementation. After this we should have the ingredients needed to actually wrap things up in an Application, hopefully. :)