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 <tlo...@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@python.org > https://mail.python.org/mailman/listinfo/db-sig > >
_______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
