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

[thierry@nekhem.com]

On Tue, Oct 01, 2002 at 05:28:54AM -0700, hazmat wrote:
> On Tuesday 01 October 2002 03:21 am, Magnus Lycka wrote:
> > At 10:45 2002-10-01 +0200, Jekabs Andrushaitis wrote:
> > >I am not saying that [psycopg] is best, however my advice is
> > >not to use Python module supplied with PostgreSQL sources...
> >
> > Why not?
> >
> >
> > In general I don't mind diversity, but I four
> > drivers for the same database seems a bit redundant.
> 
> imho, i would only use pyscopg or pypgsql. of the four they are under the most 
> active development.
Wrong! PoPy is continuing but slowly its development, exploring new ways
to make the driver more powerful. I remind you that PoPy's development
has begun in 2000, so adding quickly more and more features becomes
difficult. When we began PoPy there was only pygresql. That's right,
today there are too much drivers for postgresql, and the PoPy team is
ready to merge its work w/ others teams like psycopg team, to have less
drivers but more powerful, more featured and more stable!

> 
> basically my deciding factor is whether i want to use libpq (pgsql c client 
> lib) or python db-api or if i want to use zope, if db-api i generally would 
> recommend pyscopg as it implements db-api compliance at the c level over 
> libpq. pypgsql is a c extension binding over libpq, with db-api interface 
> written in python. if zope, i would use psycopg as it has extensive testing 
> in that area, and converts to mxDateTimes to ZopeTimes. imho, the two 
> bindings serve different audiences. 
> 
> > Any chance that some of these will merge?

We are already thinking about merging.. let others teams having the same
way

> 
> not likely.
> 
> > After all, largely due to open source, we are
> > going towards more and more of a component
> > architecture in our software solutions, and we
> > use different libraries and frameworks for different
> > parts of the system. 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.
> 
> > Thus, if we pick several of these components, that
> > do different things, we might end up with several
> > different and possibly conflicting database drivers
> > for communication between Python and PostgreSQL. I
> > haven't been bitten by this yet, but it seems a
> > bit confusing to me...
> 
> 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.
> 
> -haz
> 
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://mail.python.org/mailman/listinfo/db-sig

Best regards,

Thierry