PYTHON, ODBC

Never used ODBC with Python, but if you want to use Postgres, I'd
strongly recommend psycopg which I find the nicest and fastest postgres
adapter (certainly a lot better than Pygresql and pypgsql)

Regards

On Sat, 8 Jan 2005 18:01:01 -0600, <mstory@uchicago.edu> wrote:

I've looked into pshycho pg, it appears to be the best option, my later question
now remains, what documentation or examples would be useful in developing a
completely proprietary front end written in python. Any help finding useful
examples or documentation would be greatly appreciated.

thanks,
matt

Quoting Pierre-Fr�d�ric Caillaud <lists@boutiquenumerique.com>:

completely proprietary front end written in python. Any help finding
useful

What does "a completely proprietary front-end in python" means ?

----- Forwarded message from Matthew Story <matthewstory@gmail.com> -----
Date: Sun, 9 Jan 2005 12:40:36 -0600
From: Matthew Story <matthewstory@gmail.com>
Reply-To: Matthew Story <matthewstory@gmail.com>
Subject: Re: [GENERAL] PYTHON, ODBC
To: Pierre-Fr�d�ric Caillaud <lists@boutiquenumerique.com>

we won't be using any tools aside from psycho pg, no gui application
frameworks, ie we're not using zope, ruby on rails, etc. The front
end will only work for this particular database. This has come about
due to the complicated nature of the database, and inability of zope
to do what we need, and the problems with overhead we've been
experiencing with rails due to the size of the database. Hope this
clears things up a bit.

thanks,
matt

On Sun, 09 Jan 2005 14:56:57 +0100, Pierre-Fr�d�ric Caillaud
<lists@boutiquenumerique.com> wrote:

completely proprietary front end written in python. Any help finding
useful

What does "a completely proprietary front-end in python" means ?

----- End forwarded message -----

we won't be using any tools aside from psycho pg, no gui application
frameworks, ie we're not using zope, ruby on rails, etc. The front
end will only work for this particular database. This has come about
due to the complicated nature of the database, and inability of zope
to do what we need, and the problems with overhead we've been
experiencing with rails due to the size of the database. Hope this
clears things up a bit.

thanks,
matt

On Sun, 09 Jan 2005 14:56:57 +0100, Pierre-Frédéric Caillaud
<lists@boutiquenumerique.com> wrote:

due to the complicated nature of the database, and inability of zope

Well, I've found that Zope is very good to do a few things, and very bad
at the rest.

to do what we need, and the problems with overhead we've been
experiencing with rails due to the size of the database. Hope this

I like psycopy because selects with a lot of rows are processed
efficiently.

Look at the pydo library in the skunkweb project (google !)

I'd advise you to start writing a base class for your database object
(class DbObject) with a set of methods for setting instance methods from
query results. SELECT * then use cursor.dictfetchall() which preserves the
fields names !
Add methods for inserting and updating.
Add a mapping of fields to type converters (which are functions) to
convert non-standard types like arrays to python lists if you need them.

Then derive your DbObject class for each table, with class variables
containing the field names and types converters, which will be used by the
base class. This way you can have a derived class with almost no code.

Enjoy !

thanks for the advice,

matt

On Sun, 09 Jan 2005 20:47:08 +0100, Pierre-Frédéric Caillaud
<lists@boutiquenumerique.com> wrote: