[DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3
Vernon D. Cole
vernondcole at gmail.com
Fri Oct 25 07:59:39 CEST 2013
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"):
> DB-SIG maillist - DB-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DB-SIG