Confusion over Python drivers
in [PgSql]
|
From: Josh Berkus on 5 Feb 2010 13:34 > 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. Given that SQLAlchemy isn't for everyone, of course ... it couldn't be, or Django would use it, no? --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 5 Feb 2010 12:01 Peter Eisentraut wrote: > On fre, 2010-02-05 at 14:45 +0000, Tim Bunce wrote: > > > Does Perl have a similar mess? > > > > I don't think so. > > > > The primary database interface is DBI and as far as I can see there's > > only one DBI PostgreSQL driver: http://search.cpan.org/dist/DBD-Pg/ > > 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. I assumed it would be Perl that had confusion because of the Perl 6, but obviously it is Python. The second PL/Python server-side language that was proposed recently is taking on a whole new appearance for me. :-( -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 5 Feb 2010 09:38 Massa, Harald Armin wrote: > Bruce, > > http://wiki.postgresql.org/wiki/Python > > > > The first one listed, Psycopg, is noted as "preferred libpq-based > > driver", but the license is GPL. Isn't that a problem for many client > > applications? > > > > The licence of psycopg2 is a little more complicated; the "GPL" in that > summary just tries to sum it. The actual licence is: [from the LICENCE in > the source distribution] Wow, that is super-confusing. I am dealing with an issue now that some companies are concerned that individual names appear with our own BSD copyrights in small files. That pales in comparison to this copyright. I would never be able to recommend software with that complex a copyright. I think the community needs to look at other alternatives. (I am amazed that not only are there a confusing number of drivers, but there are a confusing number of copyright options for this single driver.) -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: James William Pye on 5 Feb 2010 21:18 On Feb 5, 2010, at 1:34 PM, Marko Kreen wrote: > py-postgresql seems to be more serious, but as it's python3 only > which makes it irrelevant today. Furthermore, if it did work on python2, it's *not* something that's going to appeal to mainstream users (Python heavy web frameworks) as it *partially* suffers from the same problem that pg8000 does. It's mostly pure-Python, but it has some C optimizations(notably, PQ message buffer). I have done some profiling, and *with a few tweaks* it's about 2x-3x *slower than psycopg2* for the retrieval of a single int column. I think it could go faster, but I don't think it's worth the work. ISTM that the target audience are folk who are married to PG, and are generally unhappy with DB-API, but do not want to buy into a "big" abstraction layer like SQLAlchemy. Sure, it supports DB-API like other drivers so it *would be* usable with frameworks, but why take the 3x *or greater* hit over a properly implemented libpq version? Finally, I just don't see the existing (often PG specific) goals that I have in mind for it appealing to the majority of [web framework/abstraction] users. > 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. Yep. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Kreen on 5 Feb 2010 15:34
On 2/5/10, Josh Berkus <josh(a)agliodbs.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |