On Sun, 07 Feb 2010 14:31:52 +0100 Christoph Zwerschke <[email protected]> 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 _______________________________________________ PyGreSQL mailing list [email protected] http://mailman.vex.net/mailman/listinfo/pygresql
