[PyGreSQL] Improvements and directions for the future

[D'Arcy J.M. Cain]

On Sun, 07 Feb 2010 14:31:52 +0100
Christoph Zwerschke <cito at online.de> wrote:
> At http://archives.postgresql.org/pgsql-hackers/2010-02/msg00351.php 
> folks are complaining about the confusing mess of PostgreSQL drivers for 
> Python and that there is not one terrific driver to rule them all.

Lord of the DB-APIs?  :-)

> In fact, there are a couple of drivers that have evolved over the years, 
> each with pros and cons, and none of them really shiny and perfect. But 
> joining forces will be difficult, since some have completely different 
> approaches, e.g. some are based on libpq, some use pure Python etc. 
> There are also different ideas how to extend DB API 2 and implement 
> PostgreSQL data types in Python.

We actually tried to merge with another once but the people involved
just stopped replying.  I think they stopped development eventually.

> But what we can do is try to revamp and modernize PyGreSQL, including 
> homepage and docs, and think about future directions.

Yes.

> First, what is our main "product" to focus at? The classic API or the DB 
> API2? We should really make that clear on the homepage. For instance, we 
> have extensive docs for the classic API, but our pgdb docs still say 
> they "need to be written" (http://www.pygresql.org/pgdb.html) so it 
> looks like the classic API is our main product and it seems some people 
> got confused by that. If the classic one is our focus, we should try to 
> improve it, otherwise we should make clear that it's deprecated and only 
> maintained for historical reasons and to provide backward compatiblity, 
> i.e. only for old applications based on that API.

Does one ot the other need to be the focus?  One thing that I have
wanted to do for a while is make the classic interface a pure Python
wrapper around the DB-API.  That way it can be used with any database
and not just PostgreSQL.  If we do that we might want to make the
classic interface a separate project.

> We will also need a roadmap for migrating PyGreSQL to Python 3.x. I'd 

I'm all for that.  I haven't looked into what is required for that yet,
especially for the C code.

> like to create an experimental branch for that. And in this context, I 
> still advocate moving to a SVN or HG repository to simplify branching 
> and merging. A bug tracker will also help in reflating development. The 
> simplest solution would be to move to SF, Google Code or the like.

I know that I have resisted SVN in the past.  I am coming around
though.  If I switch I can run it here.  I already have an SVN
repository for other projects.

> Another issue concerning future-safety on the Windows platform is how to 
> deal with 64bit Python on Windows which gets increasingly popular. The 
> problem is that PostgreSQL - including the libpq.dll - is (so far) only 
> available for 32bit and they are only slowly moving towards 64bit 
> because it does not bring much advantage for PostgreSQL itself. So to 
> use PyGreSQL on 64bit Python on Windows, we may need a 64bit wrapper dll 
> communicating with the 32bit pibpq.dll via DCOM or something. Any better 
> ideas?

I'll have to leave the Windows specific stuff to others.

-- 
D'Arcy J.M. Cain
PyGreSQL Development Group
http://www.PyGreSQL.org