Re: Confusion over Python drivers

On 2/5/10, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> > I think another difference is that the Perl DBI interface is very rich,
> > whereas the Python DB-API is quite minimal and almost forces people to
> > write (incompatible) extensions. The DB-SIG at Python that ought to
> > drive all this is also quite dead, possibly because everyone has moved
> > on to SQLAlchemy.
>
>
> For people who use Python a lot, could I have a list of the deficiencies
> in DBAPI? I've got my horse and lance ready.

I took quick glance on DBI and compared to that, DB-API does
not define specific api for:
- resultset cursors
- prepared plans
- db structure examination

OTOH, my guess is that DB-API authors assumed the first two
are used transparently by the driver, and I see no reason why
they cannot be, with current DB-API.

Last item is "rich" indeed, but seems slightly overengineered..

Now, none of the differences between drivers and current confusion
seem to be related to above points. "Hysterical Raisins" is only
good explanation about current situation.

The pg8000 / bpgsql seem to be toy projects, and anyway you dont
want to use pure-Python drivers in high-performance environments.
We are not talking about C#/java here.

py-postgresql seems to be more serious, but as it's python3 only
which makes it irrelevant today.

PyGreSQL is the oldest, older than DB-API, and so it's DB-API
interface seems an afterthought and is untested/underused - eg.
it does not support bytea.

Psycopg was the leader, especially in web-environments,
but it has non-obvious license and with dead website it does not
seem that attractive. Although it is well-maintained still.

Best path forward would be to talk with Psycopg guys about
license clarification/change.

I suspect GPL does not extend anyway to Python code that imports
it dynamically, and it does not seem to be their intention - they
even try to tell it in their current clarification, but it
is not as clear as it could be.

--
marko