Thread: Python interfaces
I am in the process of moving development from perl to python. Under perl, there was DBI, the be-all-end-all of database interfaces. Under python, there is a plethora of options. Is there a recommended one for postgres? It will be mainly used in a web environment, so the ability to work asynchronously is not that important. I am interested in maintaining database introspection (which the DB-API 2.0 is conspicuously short on) tools, as well as niceties such as automatic escape-quoting, etc, that are pretty standard in perl. Any suggestions? Thanks, Sean
Sean Davis wrote: > I am in the process of moving development from perl to python. Under perl, > there was DBI, the be-all-end-all of database interfaces. Under python, > there is a plethora of options. Actually that isn't correct. The python drivers all adhere to DB API, the drives themselves are just a tad different. You can see the spec on DB API here: http://www.python.org/dev/peps/pep-0249/ > Is there a recommended one for postgres? It > will be mainly used in a web environment, so the ability to work > asynchronously is not that important. We use psycopg2 for all python work. Sincerely, Joshua D. Drake I am interested in maintaining > database introspection (which the DB-API 2.0 is conspicuously short on) > tools, as well as niceties such as automatic escape-quoting, etc, that are > pretty standard in perl. Any suggestions? > > Thanks, > Sean > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Fri, 15 Sep 2006 13:52:20 -0400 Sean Davis <sdavis2@mail.nih.gov> wrote: > I am in the process of moving development from perl to python. Under perl, > there was DBI, the be-all-end-all of database interfaces. Under python, > there is a plethora of options. Is there a recommended one for postgres? It > will be mainly used in a web environment, so the ability to work > asynchronously is not that important. I am interested in maintaining > database introspection (which the DB-API 2.0 is conspicuously short on) > tools, as well as niceties such as automatic escape-quoting, etc, that are > pretty standard in perl. Any suggestions? I maintain PyGreSQL which used to be the one shipped with PostgreSQL before we split it off into a separate project. http://PyGreSQL.org/. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On Fri, 15 Sep 2006, D'Arcy J.M. Cain wrote: >> I am in the process of moving development from perl to python. Under perl, >> there was DBI, the be-all-end-all of database interfaces. Under python, >> there is a plethora of options. Is there a recommended one for postgres? It >> will be mainly used in a web environment, so the ability to work >> asynchronously is not that important. I am interested in maintaining >> database introspection (which the DB-API 2.0 is conspicuously short on) >> tools, as well as niceties such as automatic escape-quoting, etc, that are >> pretty standard in perl. Any suggestions? > > I maintain PyGreSQL which used to be the one shipped with PostgreSQL > before we split it off into a separate project. http://PyGreSQL.org/. I maintain a further split from PyGreSQL that supports native bind parameters and prepared statements at: http://cheeseshop.python.org/pypi/python-pgsql (using bind parameters eliminates many worries about escape quoting...) Cristian -- Cristian Gafton rPath, Inc.
On Mon, 18 Sep 2006 06:02:52 -0400 (EDT) Cristian Gafton <gafton@rpath.com> wrote: > On Fri, 15 Sep 2006, D'Arcy J.M. Cain wrote: > > I maintain PyGreSQL which used to be the one shipped with PostgreSQL > > before we split it off into a separate project. http://PyGreSQL.org/. > > I maintain a further split from PyGreSQL that supports native bind > parameters and prepared statements at: Just curious, why did you feel the need to split off another project? I don't recall ever seeing submissions from you for PyGreSQL. Did you have reason to believe that your submissions would have been rejected? -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On Mon, 18 Sep 2006, D'Arcy J.M. Cain wrote: >> I maintain a further split from PyGreSQL that supports native bind >> parameters and prepared statements at: > > Just curious, why did you feel the need to split off another project? > I don't recall ever seeing submissions from you for PyGreSQL. Did you > have reason to believe that your submissions would have been rejected? The reason I split it is is because the PostgreSQL native SQL format for bind parameters is using the $1, $2... convention instead of the Python style %(varname)s. I did not have an interest in maintaining the query parser that translates the sql query between the two to keep compatibility with those already using PyGreSQL. Furthermore, the changes I have made to PygreSQL C layer are too extensive for a "patch" - I know I would not accept something like that if it arrived in my mailbox all of the sudden... As a side note, I did sent you the patch; you replied I need to subscribe to the pygresql mailing list and send it again there for review, whihc is fine, but the pygresql mailing list processor has been on strike for the past month or so - I keep trying to subscribe to it and it keeps telling me to look after a confirmation email that never arrives. I did also let you know of my subscribing woes with no reply back from you. Anyway, the code is out there already - I needed to release it because of the fair amount of interest generated in something like that - it is not my intention to keep it split and I can contribute to PyGreSQL as soon as I am enabled to do so instead of being stuck behind a mailing list processor's issues. Cheers, Cristian -- Cristian Gafton rPath, Inc.
On Mon, 18 Sep 2006 16:48:19 -0400 (EDT) Cristian Gafton <gafton@rpath.com> wrote: > As a side note, I did sent you the patch; you replied I need to subscribe > to the pygresql mailing list and send it again there for review, whihc is > fine, but the pygresql mailing list processor has been on strike for the > past month or so - I keep trying to subscribe to it and it keeps telling > me to look after a confirmation email that never arrives. I did also let > you know of my subscribing woes with no reply back from you. Sorry I missed it. I have added you manually now. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.