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
greg@2ndQuadrant.com www.2ndQuadrant.com