Chris Angelico wrote:
In the DB API 3.0, what I would like to see is that the connection becomes a context manager that gives you a transaction object. With that transaction, you can perform queries, and you could create cursors from it if you want them, or just use a single in-built cursor. But a cursor would relate to a result set, and would have no meaning outside of it.
A while back I wrote a dedicated wrapper around the Firebird API (I wasn't impressed by the DB API, for many of the reasons being discussed here), and this is almost exactly how I structured it. Except I didn't really have cursors as an explicit concept at all -- executing a query just gave you an object that you iterate over to get the results. It just seemed the most Pythonic way to do it. It helped that the Firebird API itself was structured that way, so all I really had to do is wrap it in the most straightforward way. Is there any serious work being done on a DB API 3.0? If there is, I'd be interested in helping with the design. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
