[DB-SIG] Iterable cursor as part of core rather than an extension in DBAPI 3
Tony Locke
tlocke at tlocke.org.uk
Sat Nov 9 16:39:51 CET 2013
Thanks for your comments Daniele. I've abandoned the idea of getting rid of
fetchall(), fetchmany() and fetchone(), but I've kept the idea of execute()
returning self. I've implemented it in my fantasy DB-API 3 branch at
https://github.com/tlocke/pg8000/tree/three.
Cheers,
Tony.
On 25 October 2013 11:31, Daniele Varrazzo <daniele.varrazzo at gmail.com>wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/db-sig/attachments/20131109/f88c8d97/attachment.html>
More information about the DB-SIG
mailing list