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

[Roman Suzi]

On Mon, 2 Jul 2001, Alex Martelli wrote:

>"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?-).

Yes, ADO is what I meant.

With the recent object-orientation hype, Windows looks more attractive to
developers than UNIX. Probably ADO adds to it.

>> 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!-)

I have not tried Zope (it's overkill for our tasks) but I think
Zope must have something similar.

>> 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?

According to some individuals here it makes Python dead snake :-))))

>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)?

This is clever. Though ADO-like higher-level abstraction could
be useful.

>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.

Yes, this could be cool.

> 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

Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd at onego.ru _/
_/ Tuesday, July 03, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Paranoia is nothing to be afraid of!!" _/