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

[Vernon D. Cole]

I don't think that fetchmany() or its brothers will, or should, go away.
 I, for one, want api3 to be backwards compatible.  I suspect, however that
use of the iterator will become the prevalent pattern in the future.

I am +1 on iterable cursors being required for API 3.

I am starting a project just now which will be using SQLite.  The present
production version of adodbapi <http://sf.net/projects/adodbapi> has all of
the features that I (humbly) think ought to be in the v3 api.  Since SQLite
is the only major database that ADO does _not_ cover, I am thinking of
forking it and adding the updated features I want to use. Hopefully, my
fevered mind will cool before that happens.



On Thu, Oct 24, 2013 at 3: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.
>
> 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
>
>
>
> Cheers,
>
> Tony.
>
> _______________________________________________
> DB-SIG maillist  -  DB-SIG at python.org
> https://mail.python.org/mailman/listinfo/db-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20131024/c02d16e5/attachment.html>