[DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL
Tue, 1 Oct 2002 07:39:04 -0700
On Tuesday 01 October 2002 06:20 am, Magnus Lycka wrote:
> At 05:28 2002-10-01 -0700, hazmat wrote:
> >imho, i would only use pyscopg or pypgsql. of the four they are under the
> >active development.
> It seems popy might merge with pyscopg?
i'm interested, as user, in hearing of any benefits that this merger would
bring from a code/technical perspective. i haven't heard any yet.
open source brings choices, and thats not nesc. a bad thing.
> Is there a good reason why pyscopg or pypgsql can't
> become the standard driver which is included in
> the standard PostgreSQL database?
open source also brings community politics.
pygresql is the oldest python binding to postgres, and its developer is also a
postgres developer. so when the postgres community was deciding to include a
language binding.... although to be honest i can't recall if other bindings
were stable when pygre became bundled with postgres.
>What is so important
> with PyGreSQL if "everybody" thinks that it shouldn't
> be used?
several things, when i last used pygresql a couple of years ago, i found its
db-api interface to be horribly broken. i believer there have been some fixes
to this, in the interim *years*. perhaps most signifigantly from my own
perspective is that it plays *very* poorly with zope. to wrt, datetime
conversions, and the fact that its zope adapter executed queries serially
(which is not nesc. the fault of pygresql) .
probably one of the authors/developers of the alternative frameworks, could
better answer on why they wanted to develop a new framework, rather than
using/extending/fixing pygresql. or perhaps their time is better spent coding
> I wrote:
> > > A library or framework that
> > > is built in python and use PostgreSQL might use
> > > any of these four drivers.
> >not really, the limitations/bugs of some of the drivers will become
> > apparent quickly.
> Oh? Why does PyDO use PyGreSQL then?
i can't speak to why pydo uses pygresql, but there are a couple of reasons why
other projects use pygresql, imo. the biggest one is ease of distribution, as
pygresql comes with postgres. another one is sometimes developers are not
aware of the better alternatives
> >ideally their would be a driver framework with plugins, and we'd only have
> > to worry about the portability of our sql. as it is, most people
> > implement their own abstraction layer, as it does not seem apparent to
> > me, that the db-sig is going to promote db-api from interface
> > recommendations to framework.
> I'm afraid you might be right.
> I have a feeling that this is somehow a consequence
> of how open source projects work.
> Those who are actually doing the real work of
> developing and maintaining database drivers are
> typically happy with what they have produced,
> and see few reasons to do things differently.
well the db-sig decided not to make a driver interface frameworks to help
developers in writing adapters according to a more lenient specification.
> Those (like me) who just want to use the drivers
> in the most convenient way are typically to busy
> coding other stuff to really make a concrete impact
> on how the drivers work... It's not as if we pay
> the bills of the driver developers...
> Well, I shouldn't complain. Things are great really,
> and however much we improve stuff there will always
> be more things to complain over.
well one of the consequences of open source, is you get to scratch your own