Massa, Harald Armin wrote:
I agree that there are some performance-challenges with pure-Python drivers. And we should not forget to look for the reasons for the incubation of that many pure-Python drivers: a) Python is no longer one-language, one-implementation. There are (at least) cPython (the original), Jython (on JVM), IronPython (from Microsoft on CLR), PyPy (Python on Python), Unladen Swallow (from Google on LLVM). In addition the nearly-Pythons as in Cython, RPython and ShedSkin... especially a) is a point to consider when standard, it's getting one driver that satisfies the needs of the people most like izing on a PostgreSQL blessed Python-Postgresql-driver. How will the blessing extend to Jython / Ironpython / PyPy?

The point isn't so much "standardizing". Having a low performance Python driver turns into a PostgreSQL PR issue. Last thing we need is the old "PostgreSQL is slow" meme to crop back up again via the Python community, if the driver suggested by the community isn't written with performance as a goal so that, say, PostgreSQL+Python looks really slow compared to MySQL+Python. And if you're writing a database driver with performance as a goal, native Python is simply not an option.

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?". And as you say, nurturing the "incubation" of such drivers is completely worthwhile. I just fear that losing focus by wandering too far in that direction, before resolving the main problem here, is just going to extend resolving the parts of the Python driver situation I feel people are most displeased with.

Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to