[DB-SIG] Result Set Inconsistencies

[kevin_cazabon at hotmail.com]

As a lurker here, I whole-heartedly agree that the spec should not be
ambiguous here.  While its not a lot of work to add a list() wrapper to
calls, it's another potential for bugs, difficulties, and confusion.  It
also adds overhead to the transaction.

Is it not too much to ask that the next rev. of the spec clarify this point,
with a MINUMUM of having a preferred solution (so as to not break older
modules, but provide a framework for new ones and updates)?  At least that
way when people implement an interface they know whether to choose the red
pill or the blue one.

Kevin.


----- Original Message ----- 
From: "Kevin Jacobs" <jacobs at penguin.theopalgroup.com>
To: "Orr, Steve" <sorr at rightnow.com>
Cc: <db-sig at python.org>
Sent: Wednesday, July 16, 2003 3:52 PM
Subject: RE: [DB-SIG] Result Set Inconsistencies


> On Wed, 16 Jul 2003, Orr, Steve wrote:
> > Because results sets can either be lists or tuples (or strings?) the API
> > fails its stated purpose.
>
> You don't see the major users of DB-API drivers resonating with this
> argument, so this should be your hint that your use-case is not as
> compelling as you think.  DB-API is there to enable database access -- not
> hold your hand or write your applications for you.  If you want lists, and
> demand lists, then add the six extra characters and write:
>
>   rows = list(cursor.fetchall())
>
> If this is too much effort, then I can think of a several other ways to
make
> this easier -- and none of them make life more difficult for DB-API driver
> authors.  In this case -- less is more.
>
> -Kevin
>
> -- 
> --
> Kevin Jacobs
> The OPAL Group - Enterprise Systems Architect
> Voice: (216) 986-0710 x 19         E-mail: jacobs at theopalgroup.com
> Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com
>
>
> _______________________________________________
> DB-SIG maillist  -  DB-SIG at python.org
> http://mail.python.org/mailman/listinfo/db-sig
>
>