[DB-SIG] Popy - Psycopg - PyPgSQL - PyGreSQL

[hazmat]

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
> >most
> >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 
itches ;-)

-haz