Tao of the Machine

To generate or not to generate

In the meantime, I came up with a far-fetched solution myself. Let's recap: I want to write a portable application, that works in Python 2.1, 2.2 and 2.3. One object could benefit from the use of generators, so I want to include these generator methods if generators are present (in 2.2 and up), and exclude/ignore them in earlier versions.

Sounds easy, right? Not really. The code presented yesterday doesn't work, because the __future__ import must be the first line of the file. What about inspecting sys.version?

use_generators = sys.version_info[:2] > (2, 1)

    class Foo:
        ...
        if use_generators:
            # define generator-using methods

The solution I came up with is:

1. Create a generator-using file gen22.py with __future__ import and a class GeneratorMixin. This class has generator-using methods.
2. Create a 2.1-friendly file gen21.py with class GeneratorMixin. This class doesn't define anything at all, or maybe non-generator versions of the 2.2 GeneratorMixin methods.
3. In your main file, use this code like this:

# portable-generators.py

import sys

print sys.version_info
if sys.version_info[:2] > (2, 1):
    from gen22 import GeneratorMixin
else:
    from gen21 import GeneratorMixin

class Foo(GeneratorMixin):
    # this will now have generator methods for 2.2+,
    # but not for 2.1 and lower

More Swing

In spite of that, I will probably stick with wxPython as my main GUI for Firedrop... for now at least. Getting a Swing implementation to work will probably take too much time. However, once I got a rudimentary version working, I will consider adding a second GUI in Swing. In other words, Firedrop may have multiple front-ends, one in wxPython, one in Swing, maybe even more.

This led to an interesting puzzle, aside... the FDB had two methods using generators, which are Python 2.2+. Jython, however, covers Python 2.1 (without generators). Problem: find a portable way to include the generator methods if generators are available, and exclude them if not.

Obvious solutions like

try:
    from __future__ import generators
    use_generators = 1
except:
    use_generators = 0

# later...
if use_generators:
    # define generator-using methods here

A fling with Swing

For those who are interested, here's the code. It works, although it may not be perfect. (For example, you have to call main() after creating the class, to make everything visible. Shouldn't that have been in __init__?)

Ooey GUI

• Tkinter
• wxPython
• Jython/Swing
• Delphi

Which makes me wonder, maybe I can write multiple GUI front-ends... but I digress.

I don't want a really complex GUI. In spite of that, Tkinter as-is doesn't really look up to the job; maybe with Pmw. wxPython would be a better candidate, but will it work on the Mac? That may be very important because I might want to develop parts of the app there. Delphi is cool, but restricts the app to Windows. Jython and Swing is looking better and better. I don't know much about Java, but using some simple Swing classes doesn't seem too difficult. Of course I may be wrong, so some experimentation is required. Jython would actually have some cool benefits... you can compile the eventual "product"... and it will/should work on any system that has a recent Java VM. The Jython examples work flawlessly on my Mac. ^_^

So, I will need to do some more experimentation first... also, the GUI design isn't quite done yet. More later.

The new frame

Then there's this:

"Probably the biggest aesthetic change with the new card frames is that the focus is now more clearly on the art. For starters the art box is larger, but more importantly the card frames now focus the eye to the art. This is why, by the way, I don't agree with the assessment that the new frames are less "fantasy" than the old ones. I believe that the fantasy focus is merely different. The old frames added fantasy elements all over the card. The new frames instead draw the focus to the one card element that I believe is the most effective in capturing the fantasy flavor: the art."

The new design isn't bad. One could wonder if it was necessary though.

It's on

FDB uses the underlying file system to store files. Files are stored in subdirectories ("sections") under the root directory. Files whose names match the regular expression "^\d\d\d\d\d$" (five digits, basically, like "00001" or "82934") are considered to be "entries" (or "nodes", in FDB-speak), and are seen by the database if you loop over all entries, or over all entries in a section. Files with other names are not seen directly, but can be retrieved on demand. This allows us to store all kinds of things in a section directory without corrupting the database.

You "connect" by simply creating an FDB object with a root directory. You must also specify an encoder and decoder. By default, these are a pickler and an unpickler (yes, from the pickle module). FDB stores and retrieves Python objects, and it does so by serializing them. Currently (and by default) pickle is used, but Firedrop may use a custom serializer that is less powerful but more readable (and editable).

Some trivial example code:

f = fdb.FDB("testdb")

user = User(name="John", age=32) # some user object
# store in 'users' section with id 100
f.save("users", 100, user)

# store 42 in 'foo' section with auto-generated id
id = f.save("foo", -1, 42)

# retrieve that value again
value = f.get("foo", id)

# loop over all nodes
for (section, id, node) in f.get_all():
    # do something with node

This system is unorthodox, but I wanted a database that was as open as possible, in many ways. You can inspect and even edit files (nodes) directly, drop new stuff in a directory to add a node, add a section by creating a subdir, etc. Also, from within Firedrop (and its embedded code, templates, etc) it will be easy to access any entry you want. Thus, writing embedded code will be easier.

The system is not super fast, nor is database integrity high on its agenda. It's easy to mess up a database if you don't know what you're doing (but meddle around anyway). So don't do that, then. :-) But if you do know what you're doing, you're not stopped by obscure file formats.

I have interesting plans for Firedrop. But it will take a while to design it and write it. I haven't even decided on the GUI yet. If any (!). ;-)