On Tue, Nov 12, 2013 at 7:41 PM, M.-A. Lemburg <[email protected]> wrote:
> On 11.11.2013 10:43, INADA Naoki wrote:
> > I think having definition about what method returns Future is good.
> >
> > For example:
> >
> > con = yield from pymysql.connect_async(...) # connection may cause
> > cur = con.cursor() # cursor creation should done without asyncio
> > yield from cur.execute("...") # execute may use asyncio
> > row = yield from cur.fetchone() # fetch also uses asyncio
> >
> > for row in cur: # raises NotImplementedError
>
> This can already be implemented using e.g. gevent, provided the
> client side is implemented in Python (and gevent can thus patch
> the socket module).
>
I don't talk about "How to use connection with asyncio?"
I'm one of committer of PyMySQL and I want to support asyncio.
And I think standard api for supporting asyncio is nice.
>
> For native C client libs, this will not easily be possible, since
> the Python wrapper will typically not get access to the underlying
> socket logic, so you have to rely on native async support in the
> library.
>
> E.g. ODBC has limited support for this, but uses an active
> polling mechanism, so callbacks won't work and I'm not
> sure Futures would directly. You would have to hook up the
> polling with the async event loop.
>
Yes. So async API should be optional.
>
> What always works is using threads as a way to let other
> code continue to run. .execute() and .fetch...() usually release
> the GIL for this purpose.
>
I want to make PyMySQL works with asyncio in single thread.
Does any developers of DB connectors concern about asyncio?
--
INADA Naoki <[email protected]>
_______________________________________________
DB-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/db-sig
