Re: Confusion over Python drivers

Greg,

> The point isn't so much "standardizing". Having a low performance Python
> driver turns into a PostgreSQL PR issue.

I totally agree.

>And if you're writing a database driver with performance as a goal, native
Python is simply not >an option.

yes. Additionally: performance is not the only challenge. A native Python
implementation, without using libpq, will have to reimplement much of libpq
- just let me isolate proper escaping, and will have its own bugs.

Now, once *that* problem is under control, and there's a nicely licensed,
> well documented, major feature complete, and good performing driver, at that
> point it would be completely appropriate to ask "what about people who want
> support for other Python platforms and don't care if it's slower?".

Pure Pythondrivers do exist now; and they are allready discussed in the
summaries - which is a good thing. With my remarks I just want to recommend
that we at least should document a position for them; and a way ahead. And I
need a place to point out that Python grew a FFI with ctypes. Maybe someone
will think of a DBAPI2.0 compatible ctypes libpq wrapper ...

Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
%s is too gigantic of an industry to bend to the whims of reality