Advocasy Questions : python suitablity for a database

[Alex Martelli]

"Sindh" <skodela at my-deja.com> wrote in message
news:8mls9k$kge$1 at nnrp1.deja.com...
> Hi folks
>
> I am planning to write a database application for windows. Original plan
> was to use delphi but I am sure python can do a lot better than that.
>
> 1]Is there a very simply sql engine with disk based database for that
> purpose written in python ?

Gadfly, an SQL DB relational engine entirely written in Python (with little
crucial performance helpers from C modules, of course), _operates_ from
memory, but _persists_ to disk.  A joy to behold, and performance will
simply floor you, IF your project is compatible with the constraints
implied by Gadfly's architecture: no real multi-user operation, and
an amount of data that will comfortably fit in virtual memory (you'll
have to do some tests & measurements yourself, but that will be a
relatively small multiple of physical memory).

See http://www.chordate.com/kwParsing/gadfly.html for more.

Best of all, your Python application talks to Gadfly through the standard
Python-to-Database-API (more or less); so you can develop & prototype
with Gadfly, then, if the data is too much for Gadfly to handle it well,
you can choose to deploy with just about any relational DB you can name
(mySQL, for example) and it should be little more than some tweaking
to make it run well again.  (If you do foresee the need for such a port,
dual-developing from the start, i.e. basically run regression tests versus
both DB's as you go, may make your life easier than a big-bang port at
the end, where problems, even if minor, appear all at once).


> 2] I also need a decent GUI for the db. Which toolkit has a licence
> similar to python, so that I don't have to release the source code.
> Before you frown about this, the idea is consistency, not secrecy. The
> application I'm writing is for somewhat internal use, not public. That
> is why I don't want all users to have the source code and start
> tinkering, creating havoc in our systems.

I think wxPython is probably best; see www.wxpython.org.  Others will
no doubt pump for Tkinter, but 'wxPython rules' is my opinion:-).

If you're SURE you'll never need to port beyond windows, you have many
other options as well (but I do basically-just-windows myself, and still I
prefer wxPython...).  Specifically, the 'interactively-paint-the-window'
visual-GUI-builder approach is at a pretty rudimental stage for wxWindows
(and wxPython), and I believe other free toolkits, compared to the tools
you get with, say, Delphi or Visual Basic.  Some of us aren't very visually
oriented, and thus find that building a GUI programmatically is Just Fine,
but many excellent GUI designers ARE highly visually-oriented (that
figures, doesn't it!) and thus very much prefer rich, mature paint-the-GUI
approaches.

No problem!  Python is *excellent* at playing with others -- *very* much
including 'GUI shells' build in whatever other environment you like.  See
Hammond's book "Python Programming on Win32", published by O'Reilly;
he goes in much detail about that.  If you just love the GUI-painting ease
of, say, VB, or Delphi, then you can do the GUI-shell that way and still
easily keep all the 'working guts' of the application in Python.

An approach you shouldn't undervalue is *Dynamic HTML*.  It's "not just
for client-server any more"... if your target machines are going to have a
recent Internet Explorer release installed, that can perfectly well be your
GUI engine.  And you have your pick of a zillion utilities to paint the 'web
pages' that make up your GUI (to underscore my not-highly-visual nature,
I use Arachnophylia or GVIM for that -- but, of course, there's a huge
choice of more-visual HTML generators out there).

There is one tiny technical issue connected with how huge MSHTML.TLB,
the type-library describing the HTML DOM, has become recently -- it's
SO darn large that it blows genpy, the Python-wrapper-for-COM-builder,
right out of the water.  I've finessed that by building my own type-library
(from the IDL that Microsoft kindly supplies) and wrapping *that* one; it
doesn't have _everything_ from the latest MSHTML.TLB, but it does have
all I need (and, actually, MUCH more:-).  But many approaches are fully
viable -- for example, you could use your Python 'main program' just to
start and monitor IE, having it visit pages that _embed_ the Python scripts
(via Active Scripting); for that, you only need to wrap the "Internet
Controls" (SHDOCVW), *NOT* the full kaboodle of the DOM (MSHTML),
so it's no problem.  Personally, I prefer a very sharp divide between the
engine and GUI parts of my applications, so embedding script into such
presentation-oriented material as HTML files is not my preference, but,
hey, whatever floats your boat.  If the GUI-part and the engine-part are
cleanly separated and communicating via COM or an ORB anyway, then
I see no problem in having the GUI-part be anything you like -- Delphi,
VB, DHTML+Python, Python+wxPython, C++/wxWindows, PythonWin (a
Python 'port' of MFC, if you know and like THAT:-), Python+tkInter, or
a thousand other possibilities...


Alex