XBase for Python?

[Alex Martelli]

<andy47 at my-deja.com> wrote in message news:8u5j4r$j3c$1 at nnrp1.deja.com...
    [snip]
> Jumping on the bandwagon, can I expand the question to something more
> general. I have a requirement to build a system which would
> most 'easily' be developed in MS tools (Access, VB, etc.) as
> integration with MS Word and Outlook are high on the feature list.
>
> I'd rather not go that way and am looking at using Python + window
> toolkit for the front end and would like any help or pointers for which

You can use Python to program the system's logic, while still
relying on "MS tools" for the rest, since that's a requirement
"high on the feature list".  Python, with Mark Hammond's win32all
extensions, integrates extremely well with Windows and "MS tools".

> database I could use (must be Windows I'm afraid) as the back end.

MA Lemburg's mxODBC gives you ample choice of back-end relational
databases.  Depending on your exact needs, Gadfly (the SQL relational
DB written entirely in Python -- with a potential speed boost from
a C module for the low-level parts) may be ideal.  Perhaps handiest
to program is ADO -- you can easily get to ADO (freely downloadable
as part of MS's "UDA" -- Universal Data Architecture -- SDK) via
COM (Python speaks excellent COM, with win32all...); ADO, in turn,
can use any OleDB implementation -- ODBC, MS databases from good old
Jet to shiny new MSDE-2000 (== SQL Server 2000, without the front
end & tools; up to about 5 simultaneous users with top performance;
freely redistributable if you have Office 2000 Developer Edition,
or Visual Studio; download it from the Microsoft site), Borland
Interbase (now open-source), etc, etc.

> Also, any pointers on interfacing with MS Word/Outlook/Excel would be
> most appreciated.

That's all about COM.  O'Reilly publishes Hammond's book on
Win32 programming in Python -- lots of COM there, and Office
oriented examples too.  You do need the detailed info of the
rich and complex object models that Office applications expose,
but that's around on msdn (also online, msdn.microsoft.com)
and the "Visual Basic Help Files" of Office itself (you do
need to know 'just enough VB to get by' to be able to read
the example code in the docs -- it's all in VBA terms -- but
that's really trivial).  There are also excellent books on
those object models, and on using Office as a platform for
application integration; they're not Python-oriented, but once
you get the gist of how to talk COM/Automation from Python, it
does not matter any more that you are using Python (as long
as you remember to [a] run makepy on all of the relevant type
libraries, [b] respect _case_ -- Python IS case-sensitive!-).

Part of the Outlook object model is exposed (slightly more
generally) as "CDO" ("Collaboration" something or other), but
I don't think that's an issue -- you may well program to
whatever Outlook itself exposes in the way that's handiest
for you (you only care whether it's 'MAPI' or "CDO" or
whatever if you want to keep the door open to possible future
uses of other communication programs, e.g. Lotus Notes, in
lieu of Outlook... just like using ADO or ODBC in lieu of
native exposed functionality of whatever specific database
you use today benefits you by letting you more easily change
the underlying RDBMS in the future).


Alex