Python and DB support (was: Re: Is Python Dead?)

[Alex Martelli]

"Roman Suzi" <rnd at onego.ru> wrote in message
news:mailman.994100826.19440.python-list at python.org...
> It seems I start to understand database concerns of Mr. Wilson the second.
>
> Once we tried 3 databases (MySQL, PostgreSQL, Interbase) to suit our task.
> And for every database (we stopped at Interbase) there was Python support.
>
> However, my collegues were not satisfied with it. One somplain was that in
> ASP/IIS it is "very easy" to receive a "recordset" from database and then

Internet Information Server (IIS) serves webpages, including Active
Server Pages (ASP), but neither has anything to do with database access.

What you're using to access databases in such a setting is most likely
MSDAC (MicroSoft Data Access Controls, I believe) and specifically the
ADO (Active Data Objects, I believe) part thereof.  So if that's what you
like, why not access it from Python?  I happen to like it quite a bit too,
and as it happens Python + win32all makes it a snap to use it (on a
Win32 platform, only, of course -- but then, that's where IIS runs, too,
or has MS released it for OpenBSD lately?-).

> apply it in different situations in the ASP-page, because recordset is an
> object and even subqueries could be made without quering DB again.

Yep, the recordset part of ADO is undoubtedly the most popular single
feature of it among us lazy programmers.  You can even disconnect from
the DB and keep the recordset around, persist it to a file (maybe in XML),
depersist it later... it's fun!-)

> From this and also from my own experience with PostgeSQL queries from
> Python, I could say that DB support in Python exists, but need enhancement
> and standartization. Probably, higher level more or less common
> object-oriented interfaces could help this.

It seems to me the (DB API 2) standard is fine (maybe a bit too
ambitious, so actual implementations may not have reached up
to it yet?-).

> I must also say, that I myself am completely satisfied with Python DB
> support, but I do not use DB extentensively and routinely to judge.
> However, I think that including some more DB support, at least for open
> source databases like Postgresql and MySQL + ODBC/JDBC, could be a good
> idea and will give a standard. (Yes, I know about Python DB API).

And?  What's wrong with it?  What support would you get from ODBC,
portably between Postgres & MySQL, that the relevant DB API modules
don't supply?  Maybe we could supply an ADO-recordset-workalike on
top of any DB API compliant implementation, that might be handy at
times I guess.  But hardly a make-or-break thing, no?


> Are there licensing problems or what stops from letting RDB support
> modules into standard library?

Why would I want to have to download support for many databases
I don't use each and every time I download Python?  It's bad enough
getting the Irix or Mac stuff as a part of my (e.g.) Windows d'load --
why would I want Postgres and/or MySQL and/or Oracle and/or SQL
Server and/or (&c) if what I end up using is Interbase (as you did)?

If I had a vote, I'd rather seen _Gadfly_ tuned up (out with regex
and regsub, in favour of re; minimal-tolerance support of stuff it
does not implement, such as NULLs) and made a part of Python.  It
might give a taste of SQL to SQL-unaware programmers and it would
provide a DB API implementation (usable like dumbdbm is as the
last-choice fallback for anydbm, if you see what I mean).  But it sure
wouldn't be THE db of choice for demanding professional use -- go
see Oracle or SQL Server for that, or maybe Interbase, MySQL &c if
that's what rocks your boat.  The DB scene seems just too fragmented
at this point in time to warrant including support for 10% of it in
the standard Python library, I think...


Alex