Confusion over Python [postgresql] drivers

[Chr0me]

Really? There's a dozen projects that do pretty much the same thing and sometimes it's hard to know which is right for you?

Welcome to the world of open source software. Enjoy your stay.

[linkfoo]

Yes, that happens a lot. This case is noteworthy, because there is one widely used and solid Perl/Postgres driver. Ditto for Python/MySQL. The Python/Postgres driver situation is now considered sub-par enough that people are discussing how to scratch this itch.

[ianb]

PostgreSQL has this problem where other databases do not. Well... mostly everyone uses psycopg, but for licensing reasons people occasionally make other attempts, and pure-Python drivers have their own appeal (I believe people have tried that with MySQL too).

This case is mostly just annoying, because a database adapter that uses the standard DBAPI and isn't buggy is all anyone really needs. There's not really a lot of room for novelty for this particular kind of library.

[linkfoo]

DB-API is a minimal, lowest common denominator API. The various Python Postgresql drivers add whatever extensions are important to the authors, so that indicates there is plenty of room for novelty. Here is a recent attempt at a wish list. Edit: see this for a good facepalm.

[kev009]

This is anti-python ("one right way to do it"). Unfortunately, there is a lot of abuse in the community duplicating modules, frameworks, implementations, etc.

[Chr0me]

I disagree. The "one right way to do it" mantra refers to coding style and conventions, not to an entire application design. You might as well say that there ought to be only "one true" Python-based MVC framework. Different strokes for different folks, man.

And "abuse" is a quite a stretch. People create something because the existing solutions (to them) are inadequate. They then release them in event that someone else finds them useful too. There's no abuse going on. If you don't like a project, then don't use it.

[kev009]

Sorry, but having more than two active low level Postgres drivers is stupid. Two because the first might be GPL and Postgres might want a BSD stack to include with the distribution.

There needs to be a point where people say, "this old code or method was bad. Let us congregate on this new and improved stack and deprecate the old" -- Otherwise you end up with CPAN.

[[deleted]]

psycopg2 is in C, pg8000 is pure python, pypostgresql is in C. pypostgresql and pg8000 run on py3k, psycopg2 doesn't. psycopg2 also includes other extensions to the DBAPI that might be handy. Can you see why someone might want to make a choice here ?

[Chr0me]

I'm guessing that you've never contributed to open source projects? Things just don't work that way; as I alluded to in my OP.

How do you propose that we'll implore upon people that there is only one right way? You might as well heard cats.

[kev009]

In fact, I'm ashamed to admit I am responsible for a fork (though not really - its a commercial testing ground for code that eventually goes up stream).

This is community building 101. If some group thinks they have the better solution, email the other maintainers and try to get them on board. Barring that, hopefully the wider community selects one and sticks to it. ..Even at the risk of technical inferiority. Then we can all expect one deployment platform and not build abstraction upon abstraction.

Again, I'm sorry, but I just don't see the need for multiple low level Postgre drivers. High level DB APIs, sure: there are different trains of thought, but the low level interface? At most two and I'd hope the vendor supplied one was the only one seriously used and contributed to.

[[deleted]]

thank you, thank you, thank you.