Re: #99: Patch for cursor.execute and cursor.executemany to return cursor object

> I assume that you really meant to write this:
>     for login, in cursor.execute("select login from users").fetchone():
>         print login

        His example would work : a cursor is an iterable which yields rows :

for id, login in cursor.execute("select id, login from users"):
          print id, login

would print the ids and logins of all users.

for id, login in cursor.execute("select id, login from users").fetchone():
          print id, login

would fail, because fetchone() would return one [id_value, login_value].

Now I'd like this :

for id, login in cursor("select id, login from users"):
          print id, login

I find the DBAPI way a bit kludgey...

When I only need 1 cursor for quick scripts, I use some helper function
which does this.

def Query( sql, *args ):
        cursor.execute( sql, args )
        return cursor.fetchall()

for id, login in Query( "blah" ):
        ...

Oh, and by the way : thanks for psycopg. The speed of this thing is
insane. FYI the postgres driver for PHP is about 10 times slower, without
doing any object adaptation.


> which does save a few keystrokes over the current:
>     cursor.execute("select login from users")
>     for login, in cursor.fetchone():
>         print login
>
> Although there is some appeal to the one-liner approach, it is important
> to remember that most of the external interface of psycopg is not
> actually dictated by psycopg: it's the Python DBAPI.  We can't
> arbitrarily invent new behaviors.
>
> I agree with Federico on this.  Some day, the DBAPI crew may decide that
> execute() should return something (success/failure code? record count?
> I don't know), and psycopg needs to be able to respond to that without
> breaking existing applications.