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
