Would just like to mention that I am using KInterbasDB
(now at version 3.x), the Python DataBase-API 2.0 compliant
binding found at kinterbasdb.sourceforge.net and so far
it rocks! Definitely a Pythonic API.

I'm using kinterbasdb in conjunction with some homegrown
Python curses-based text widgets for a fairly straightforward
inventory app.

I though of using Kylix to write my inventory app in,
but its resource requirements (I'll be running the
client together with the Firebird server on a 32MB
Pentium 200) and presumably complicated setup if you
don't use it with the supported Linux distros (I'm
using Slackware 8.1) turned me off.

I investigated the text UI route and decided to go
with curses. The Python curses API is quite a pain to
deal with. I believe this has more to do with curses'
design than Python, In retrospect perhaps python-slang
would have made for a cleaner, but less standard (since
python-slang does not come with stock Python) approach.
Also, afaik, the python-slang API is nowhere near as
completely documented as the curses one, you have to
consult the C slang API docs instead.

One big advantage of using curses is that I can get my
app working easily in a telnet session - I've tested
telnetting to my Linux machine from under Windows using a
telnet client and the app worked fine. Not sure if the same
can be said of a python-slang based program but compared to
trying to work with a Kylix program remotely via X, it is
a whole lot simpler.

Despite all the frustration dealing with curses, the more
sophisticated widgets I've managed to come up with after a
couple of weeks of pain are drop down lists and a multi-column
browser whose input fields can also contain drop down lists!
While my widgets are functioning fairly cleanly, the internal
architecture is far from being as clean as I would like it to
be.

Attached is a screenshot for those who might be interested
in seeing what it looks like.


[Non-text portions of this message have been removed]