Because of no availability of mbox archives, this message will not
appear in the right thread ;-)
* Edmund Lian <[EMAIL PROTECTED]> [2002-05-17 20:22 -0400]:
>
> Gerhard wrote:
>
> >I'm new here.
>
> Welcome! What a pleasant surprise to see you here. Your timing is
> excellent, because you're the right man to educate us on the different
> Python-PostgreSQL modules! :-) I'd just posted a query yesterday asking
> for opinions/experiences about psycopg and pyPgSQL.
>
> You chose to devote quite a bit of time to working on pyPgSQL rather than
> use or work on one of the other modules.
First, to be honest, I've never had a chance to use Python/PostgreSQL
for real projects, so I've only used them for my personal pet projects
and for the fun of hacking on them.
I originally used PyGreSQL and ported it to Windows, but quickly found
it to have annoying bugs, and so I had another go at porting one of the
other alternatives to Windows, pyPgSQL looked like it was the easiest to
do, and I prefer BSD-licensed Python modules to LGPL or even GPL
licensed ones. This was how I first made contact with pyPgSQL. Making a
Windows patch was very easy, it mainly consisted of writing a setup.py
and replacing the old-style Python build process with the
Makefile.pre.in. After one or two iteration of submitting Windows
patches, Bill Allie suggested to add me as a developer. That's how it
began :-)
> If you have the time, and care to do so, would you explain what about
> the other modules drove you to hacking/using pyPgSQL? What advantages
> and disadvantages should we be mindful of when chosing one module over
> another?
Let's first say I agree with your choice that pyPgSQL and psycopg are
the ones to consider at this time. I personally don't like how PyGreSQL
is developed, and in the past, I clearly said what I think about this. I
mean, all the other modules (PoPy, pyPgSQL, psycopg) have started when
PyGreSQL already exists, so you can figure there was a reason for
starting them. PoPy, on the other hand, seems unsupported. And the last
thing they publicly said is that they want to move the development off
Sourceforge to the Nekhem site. That was, what, about a year ago or so,
and you won't find anything PoPy related on the Nekhem site. I don't
know the details, but AFAIK psycopg was started as a new implementation
with lessions learnt from PoPy (some of the developers of psycopg were
PoPy developers).
I can't say anything bad about psycopg, except that it's GPL (as is PoPy
now, earlier releases were LGPLd). It depends upon your
reli^H^H^H^Hpolitical feelings wether you like this or not. I don't like
GPLed libraries.
I'd like to make clear that pyPgSQL is not unmaintained. It's just that
Bill Allie, the project admin, has very little time at the moment, so no
release was made since October 2001. But quite some stuff has happened
in CVS since then:
<plug ask="please excuse">
- Several bugfixes from Bill Allie
- Transaction isolation level support from Bill Allie
- The CVS version is compatible with PostgreSQL 7.2 (The PostgreSQL
folks changed the way ARRAYs are represented in Pg 7.2 beta 2 :-/)
- pyPgSQL is AFAIK only PostgreSQL database interface (I checked Python
and Java) that correctly implements ARRAYs. This now works with
PostgreSQL versions 7.2 and earlier (both ARRAY forms are supported in
the Parser)
- pyPgSQL is the only PostgreSQL interface at all that supports
multidimensional ARRAYs (ok, nobody in their right mind would actually
use these)
- A Unicode patch is in the works (available at Sourceforge) and waits
to be tested by two people that showed interest in it
- two days ago, I committed a change that makes the mapping of column
names to column numbers a per-resultset attribute instead of a per
row-attribute. This saves a lot of memory and also slightly improves
the performance of fetches.
- Locally, I've the start of a patch that naively reimplements the
TypeCache which in early tests shows that this approach can double the
performance of fetches
</plug>
Which leads us to the next point: performance and do you need it.
I'm no great benchmarker, but I'll make no secret of it. If you build a
naive benchmark, psycopg will win by far over pyPgSQL for fetches. I
think I've successfully located the performance bottlenecks in pyPgSQL,
btw. OTOH it's quite unlikely that the database fetches really become
the performance bottleneck in your application, after all, what good is
a:
for row in cursor.fetchall():
pass
;-)
If you absolutely need performance of fetches, because for example you
do a lot of calculations on them in Python or in a C extension module,
then psycopg is a very good choice, IMO. But that's probably not what
SQL is for and for normal applications, I doubt that pyPgSQL's
performance is a problem. It's design is using OO techniques a lot and
currently favours implementation complexity over raw performance. Again,
I think this is no problem in the real world.
Another point the psycopg folks are keen on is their support for using
the module in multithreaded environments. To be honest, I've never
needed to share a connection on multiple threads, and AFAIR PostgreSQL
connections aren't thread safe, so they sure must have played some
tricks to work around this limitation. It's one of the design goals of
psycopg to work well for heavily multithreaded applications. I haven't
tested this, cos I never needed it. But I can say that this is probably
better tested on psycopg than on pyPgSQL. If there are problems with
this and pyPgSQL, however, I'm sure they can and will be fixed. Just ask
on the mailing list.
One point where pyPgSQL is better than psycopg is its type system, as it
supports almost all PostgreSQL types natively with appropriate types: it
has PgInt4, PgInt8, PgNumeric, PgInt2, ARRAY types, and others. psycopg
only uses Python types, which isn't appropriate at least because of the
lack of fixed point support (very ugly when you have currency data).
To make a long story short, I think pyPgSQL <-> psycopg mainly differ in
features <-> raw speed, multithreading.
Sending this including spelling and grammar errors, cos it's too late
already :)
Gerhard
--
This sig powered by Python!
Au�entemperatur in M�nchen: 17.3 �C Wind: 1.4 m/s
_______________________________________________________________
Hundreds of nodes, one monster rendering program.
Now that's a super model! Visit http://clustering.foundries.sf.net/
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
