Postgres support

Alex Martelli aleaxit at yahoo.com
Sat Jul 7 16:56:44 EDT 2001


"Steve Williams" <stevewilliams at wwc.com> wrote in message
news:3B4719E1.C5540B19 at wwc.com...
> Alex Martelli wrote:
>
> > "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.
> > >
> > A SINGLE module to handle five or more mutually incompatible
> > interfaces?!  That's utterly ridiculous --
>
> Take a deep breath, now.  Calm, calm.
>
> I can dream of a paradise with python and wxPython/wxDesigner and a
> hypothetical pySQL92 universally available, pre-compiled, waiting only to
be

SQL92 API is _one_ interface, not five, and I suspect that DB2, Informix,
&c don't support it fully (do they?).

> downloaded and installed on more platforms than WinTel.

Assuming I did have a Python API DB 2 implementation, coded against
the SQL92 API standard, I'm not sure it could even be _compiled_ in a
single way (doesn't SQL92 define certain preprocessor macro names that
a compliant API implementation can define differently?) and surely it
cannot be *prelinked* (against libraries of unknown names...?) in any
cross-platform way.  Is this a *PYTHON* issue?  What other languages,
libraries or utilities manage to deliver a cross-platform "pre-compiled"
(and pre-linked?) interface to SQL92 API "waiting only to be downloaded
and installed" on many platforms?  Particularly one that supports Sybase,
Informix, Oracle, DB2 AND Microsoft SQL Server transparently?!

> Not all that far-fetched, IMO, although I'm prepared to ignore those who
> urge me to do it myself.

Totally far-fetched IMO, even IF all the mentioned db's did support
the SQL92 standard API (which I don't believe is the case).  I'm quite
ready to adapt some existing Python DB extension to use the SQL92
API instead *IF* somebody could ensure such a huge (far-fetched)
deployability of the resulting precompiled binary.  I just think that it
is VERY far from the realm of the possible.


> As far as ADO, well, I fear it might be part of a subscription-only
revenue
> model in the future.

Perhaps.  So let's start doing XPADO on top of XPCOM just as ADO was
done on top of COM, shall we?  Technically, for all of its slight faults,
COM/Automation/OleDb/ADO is a pinnacle of cross-language component
base infrastructure.  XPCOM has apparently managed to implement a
faithful-enough rendition of the first (lowest) layer, and PyXPCOM might
do the same for the second (Automation) -- aren't we almost halfway?-)

But most likely the usual crybabies will still be crying about "RAW" (sic)
C-level interfacing (to a zillion incompatible proprietary idiotic API's, no
doubt -- the fact that there IS a solid, well-developed standard doesn't
count:-).  So, naah, not worth the bother.


Alex






More information about the Python-list mailing list