Re: Trying to use PyDO under cygwin

On Thu, Aug 19, 2004 at 02:48:41PM +1000, Jonathan Kelly wrote:
>   File "D:\PYTHON23\lib\site-packages\PyDO\PyDO.py", line 11, in ?
>     from static import *
>  ImportError: No module named static
> 
> OK. I had noted that there was a PyDO.py and PyDO2.py and that the 
> comments in PyDO2.py mentioned something about doing away with static, 
> so I saved PyDO.py and moved PyDO2.py onto PyDO.py and tried again.

static.py is also in the SkunkWeb distribution -- in pylibs, as is the
PyDO package.  So you don't have to use PyDO2.  And if you do I would
suggest taking a look at the CVS version. 

> NameError: name 'string' is not defined
> 
> Hmm. Had a look, and tried the simple thing of adding import string to 
> the PyDO.py (which was PyDO2.py) and tried again.

Sorry about that.  I believe that is fixed in CVS.  We haven't done a
release in a long time.
 
> TaDa! No crash. Now to try actually doing something.
> 
> Hmm ... more than an two hours later, I finally have it working.
> 
> psycopgconn.py is full of bugs. Syntax errors even. I've fixed a few 
> things, but have no idea what is supposed to be happening, as this stuff 
> "seems" beyond my Python skills, which I consider meager. 

You mean "used to be meager, until I fixed this broken code"!

I apologize for psycopgconn.py having been thrown in there without
being tested.  Someone contributed it, and I checked it in planning to
test it later -- and I wasn't using a tagging convention to keep alpha
code out of releases.  In fact, I've never used it -- I've been using
the pygresql interface -- but for this and other reasons I want to try
psycopg, so I'll see if I can't clean it up a tad, and will get back
to the list when it is.

> I'm happy to help and feed stuff back, but it will need some supervision 
> as I'm very newb to python and postgresql, but not an idiot though.

Your help is much appreciated. 
 
> All I really wanted to do is find out if PyDO was nicer than raw SQL.

I believe it comes in handy quite a lot.  Be aware that there is
always the escape hatch of SQL when you need it or when PyDO would be
grossly inefficient (e.g., because you don't want to do "SELECT *").
So I see PyDO as a translucent abstraction layer, not an opaque one.

Cheers,

Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBJaQluqamFyFXXLIRAqh3AJ4g3PDJ7OBODucI8LvDbWuUuTnJ6ACbBDSr
i7Izzz49xPR6gGdxKknkqqU=
=sv/e
-----END PGP SIGNATURE-----