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

Zen zen at shangri-la.dropbear.id.au
Tue Jul 3 01:50:41 CEST 2001


"Alex Martelli" <aleaxit at yahoo.com> writes:

>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'm preparing a PEP to address a few issues with the Python DB API
and an initial draft has been presented to the DB-SIG.

I'm unfamiliar with ADO. When you retrieve a recordset, are all
relevant tuples retrieved from the database (like the Cursor.fetchall()
method in the DB API)? Or is it a lazy object that only downloads
the rows when they are accessed by the application (like the Cursor.fetch()
or Cursor.fetchmany() methods in the DB API)?

Can you provide examples of things you can do using the ADO interface
(don't care what programming language) that are difficult to do using 
the Python DB API? Even if it is outside the scope of *this* PEP, I need
to understand peoples wishlists to ensure they can be integrated
in the future.

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

The 2.0 driver implementations of the major databases seem fine to me.
One problem I notice with database tools is extremly rare for someone
to deal with more than three vendors RDBMS implementations, and generally
people only develop with one or two. 

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

>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

I agree that it would be a benefit and worth a PEP if the
Gadfly author agrees and someone volunteers to do the
required tweaking.

I don't see a point in including drivers in the core for databases that
follow a different development cycle. Last thing we want is obsolete 
PostgreSQL drivers out there when a new version of PostgreSQL is
released. Although PHP manages to do this.... can any PHP users comment?




More information about the Python-list mailing list