Developing Upwards

I'm toying with the idea of a new way to write tests. This is a cross between state and interaction based testing, and also tries to make setting up the test environments easier. I call it "Flow Testing" as it tests how the various states of the test target flow from one to the next. The idea is several-fold. We begin on the idea that we are testing names, because everything in Python starts with a name. You will test different things about names, such as type, what attributes or other properties apply to certain conditions, etc. Flow testing is very tree-oriented. For every name, you define the state you expect to begin, and branch into the state you expect for various properties. For example, you may have a state for the name 'foo' and a branch state for 'foo.bar'. These are branches within one state, while wthere are other branches across states called Interaction Branches. These states define the interactions that lead to them and the states expected. ...

I am on vacation. It is very, very nice. Even before this, things have been slow. On the edge of worryingly slow, but still not slow enough that I've had to fret over anything. I've been enjoying some relaxation and time with my growing baby boy and my beatiful wife. We've taken the holiday with her family and our friends in sunny North Carolina, where I have been enjoying warm, sunny weather to start my winter. I actually miss the cold. Although not much has happened externally, a lot has happened internally. I am using the down time to organize myself, my plans, and prepare movements forward for proper exploration of some plans I've had on the back burner for a while now. More of my time has been able to be spent on more recreational activities, as well, and that is nice. Reading has been lost to me for some time, and I've picked up a few books I've enjoyed. I plan to start another blog, which will be focused on reviews of literature developers, gamers, and ot...

I released ExtSession 0.3 today. Added error reporting through the result objects, iteration over remote objects, cleaned up much of the code, and did a some bugfixing. Also included a tutorial on extsession usage, so hopefully some of the people that had difficulty can read that and understand how to use it. Go and get it. EDIT: Fixed a broken link! What a way to mess up a release, no matter how small.

As a support package for some other things, I've written a little module called ExtSession. The basic idea is to have an easy way to control a python session running in another process. You can simply instansiate the ExtSession class, and call the execute() method. The results are asyncronous-like, but will be improved later. Very likely support will be added to get Deferreds. For now, you can simply poll or wait. The results of each execute() call (best done one line at a time) are seperated and returned individually of output from other commands, making it very easy to work with over a session's lifetime. Following is a stripped pydoc pull of the docstrings. I hope someone finds this as useful as I think I will. NAME extsession FILE /home/calvin/extsession/extsession.py DESCRIPTION ExtSession Module For executing code in an external interpreter. There are many cases where operations are either intensive or blocking by waiting, and in both situations th...

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful...