XBase wrapper for Python

[David Rushby]

"Andy Dent" <dent at oofile.com.au> wrote in message
news:dent-0602031720530001 at 192.168.0.1...
> In article <7876a8ea.0302051847.2d9b2948 at posting.google.com>,
> woodsplitter at rocketmail.com (David Rushby) wrote:
>
> >My not-too-well-researched impression is that when
> >it comes to Python-dbase modules, there's a lot of hot air and not much
> >stable code.
>
> Is there much need?

I don't think so, but I guess it depends on whether you define "much" as
"intense" or "broad".

Anyone who needs access to information in xbase-format files, and happens to
be a Python programmer, probably feels a rather "intense" need.  However,
I've read that widely used tools such as MS Excel and MS Access can extract
data from xbase files.  I imagine that most programmers in this situation
would hack together a way to extract the data to CSV (and thence to
$MORE_MODERN_DB_OF_CHOICE) based on a third-party xbase-reading tool that
was not integrated with Python.

This wouldn't address writing data back to the xbase files, of course, but
the necessity for that seems less likely.  In many instances, the legacy app
that uses xbase is extremely mature code that "Just Works", and has other
attractive features that could not be easily replaced in freshly written
code.  So management wants to leave the legacy app undisturbed, yet
batch-extract the data to facilitate more sophisticated analysis or one-way
integration with more modern info systems.

About six months ago I replaced a 386/16 running DOS 3.3 that had been
plugging away almost untouched for nine years.  The case apparently hadn't
even been vacuumed for five years.  A decommissioned Pentium 75 served as
the replacement.  The point of this anecdote is:  once businesspeople get a
tool functioning both predictably and adequately, they want it left alone.


As to whether there's "broad" need, it seems not.  The Python+xbase topic is
raised in c.l.py about three to six times a year, which isn't very
frequently:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&scoring=d&q=pyth
on+xbase+group%3Acomp.lang.python&btnG=Google+Search


> The Personal OOFILE engine is cross-platform C++ providing dBase-III+ and
> dBase-IV file access (no indexes used). One of my "is it worth it" ideas
> is a Python interface to OOFILE.
>
> Would people buy a Python interface that shipped with a compiled library?
> How much would you pay for such tools?
>
> Personal OOFILE as source is currently US$99.

"People" might, for sufficiently small values of "people".  Almost certainly
not enough to commercially justify the time invested in writing the Python
interface.  If you take the union of the set of people using xbase-based
databases with those using Python with those who readily purchase commercial
software, I'd wager you're left with a market that gives new meaning to the
term "miniscule".


One final factor to consider is that there are a couple of open source xbase
libraries that appear to be "almost there".  For instance,
http://sourceforge.net/projects/xdb/ .  That library even claims Python
support, though I don't see anything in the CVS repository to substantiate
the claim.  All it would take is for a Python/C programmer who happens to
have an "intense" xbase need to come along and write a binding.

I have merely a curiosity--not a need--nor even a belief that there's broad
need.  And I'd write my own binding to an existing open source xbase library
before I'd buy same.  So there went 33% of your prospective market ;)