[DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3

[Daniele Varrazzo]

On Thu, Oct 24, 2013 at 10:57 AM, Tony Locke <tlocke at tlocke.org.uk> wrote:
> Hi, in DBAPI 3 is there a plan to bring the 'iterable cursor' extension into
> the core? Looking at https://wiki.python.org/moin/DbApi3 I couldn't see
> anything. The reason I ask is that I'm noticing on PG8000 that the time
> taken to execute the warn() for each call to next() is significant for
> iterating over a large number of rows.

PG8000 is pretty much free to not raise the warnings, if it creates
problems and you report it as a bug to its developers. Of course the
warning could be also raises once with a lightweight check instead of
relying on the Python machinery to suppress duplicates, if it gets in
the way. I don't think the deficiencies in an adapter's implementation
should be driving the standard's design.


> I'm on the verge of suggesting getting rid of fetchmany() and just having
> the iterable, and making execute() return the cursor. Then instead of:
>
> cursor.execute("select * from emp")
> all_emps = cursor.fetchmany()
>
> you'd have:
>
> all_emps = [cursor.execute("select * from emp")]
>
> or you could do:
>
> for emp in cursor.execute("select * from emp"):
>     pass

>From this example it seems you want to get rid of fetchall() instead.
Fetchmany has other useful use cases. In order to enable the idiom of
the example, if a cursor supports iteration, it is enough for
cursor.execute() to return "self": IIRC some adapters do that, and I
find it a clever idea.


-- Daniele