Re: Confusion over Python drivers
От | Marko Kreen |
---|---|
Тема | Re: Confusion over Python drivers |
Дата | |
Msg-id | e51f66da1002051547o6d518ec0xbed257b7111e2883@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Confusion over Python drivers (Greg Smith <greg@2ndquadrant.com>) |
Список | pgsql-hackers |
On 2/5/10, Greg Smith <greg@2ndquadrant.com> wrote: > The issues here have already been identified: the Perl DBI is an excellent > spec, while the Python one is so weak everybody ends up needing their own > extensions to it. And then portability *even among Python PostgreSQL > drivers* goes out the window. Well, no. You are overplaying on the DBI angle. If the driver can offer via the minimal DB-API the same features the DBI driver can offer, then the DBI API is bloated, not the minimal API weak... Not that DB-API is perfect, a way to toggle prepare and db cursors on/off in per-query basis would be good to have, but thats mostly it. Rest of extra features (COPY) need to be done as extensions anyway. But all that is off-topic to the current driver suckiness. The problems with Python drivers are that they fail to implement even the minimal DB-API 2.0: - correctly, across all interesting data types. PygreSQL (bytea). pg8000 (does rollback after query fails - WTF). None ofthe drivers seem to support both array and tuple. - robustly. Psycopg2 - their misguided attempt to turn DB-API calls optionally async cost their stability big-time as itcomplexified their codebase. It got stable around 2.0.[678]. I'm not holding my breath on the other ones. Fear the fancyAPI-s. - with threadsafety level > 1. (I don't care, but seems in some circles it's necessary.) Note how many ways a driver can suck without stepping above basic DB-API 2.0. > If somebody built a BSD/MIT licensed driver > that replaces every useful feature of all the forks, with no major problems, > and a couple of major projects switched over to it (think "Skype" level > big), maybe this mess could get resolved. I think it would take someone > already familiar with the major issues involved a couple of months of > regular work to make any serious progress on it. Yeah, but the problem here is that there actually is not a problem. Psycopg license is not bad, just confusing on first sight. And website problem can be fix by advertisinghttp://wiki.postgresql.org/wiki/Psycopg as new website... If your requirement is BSD license, then probably getting PyGreSQL into shape would be faster than writing from scratch. Main dev effort would be writing Postgres-specific DB-API 2.0 testsuite anyway. It's likely that actual improvements needed would be small. Also I would suggest to match Psycopg extensions API, that would make it usable to much broader audience. (Eg: PygreSql does not offer COPY extensions via the DB-API 2.0 API. It would be good to match Psycopg here, instead inventing new API.) -- marko
В списке pgsql-hackers по дате отправления: