Postgres support

[Alex Martelli]

"Edward Wilson" <web2ed at yahoo.com> wrote in message
news:5174eed0.0107061058.5446dac9 at posting.google.com...
> This is exactly what I have been talking about for *years* now.
>
> Python will only appeal to scientific developers researching the
> "impossible to do" until it handles databases on a first class scale.

To try and defend this outrageous thesis, please explain why
C++, Java, Visual Basic, Perl, and other languages whose
database support is strictly comparable to, or lesser than,
Python, do NOT by any stretch of the imagination "only appeal
to scientific developers" &c.

> Oh, and another point, ODBC is dead.  Microsoft has already abandand
> it for OLEDB a COM based library.  References to ODBC need not apply.

I have sympathy for this thesis, but Java does seem to be doing
fine with the strictly-equivalent JDBC package.  So why is ODBC
no good for Python if JDBC is good for Java?

> What is needed are RAW Native Drivers at the C/C++ level.

Non sequitur!  You just mentioned (albeit with rather questionable
spelling) Ole/Db -- which is a low-level interface, not really meant
for use at application-level, but, rather, is wrapped by higher-level
ADO at app-level.  Python does VERY well driving ADO, and, through
it, Ole/Db.  So why should Python regress down to "RAW" native
drivers rather than progress to even better ADO and Ole/Db use?


> Python needs a ready to use cross database module which handles
> Oracle, DB2, SQL-Server, Sybase, and Informix.  If it handles Postgres

A SINGLE module to handle five or more mutually incompatible
interfaces?!  That's utterly ridiculous -- WHY would anybody want
to download lots of code he'll never use (and suffer the implicit
consequences of complication in the front-end code he does use)
rather than get a single SPECIFIC module (with a uniform API,
of course) for the specific RDBMS he's interested in?

IBM's acquisition of all of Informix database business was, btw,
completed the other day -- I think this includes all rights to the
NAME "Informix", so that the company previously so named is
now named "Ascential".  Presumably, the API's exposed by DB2
and the Informix RDBMS are slated to get closer and closer.  How
much sense would it make today to spend effort to support,
specifically, the Informix product as a separate one from DB2...?

But that is an aside -- the point is that THERE ARE good modules
supporting each single one of the databases you've named (and
more besides) while presenting a reasonably uniform interface
(the DB API 2.0) to Python client-code.  What added value would
there be in rolling half a dozen or so of these separate modules
into one non-modular module that makes a mismash of it all?!


Alex