[Python-ideas] async objects

Nick Coghlan ncoghlan at gmail.com
Tue Oct 4 07:30:36 EDT 2016


On 4 October 2016 at 17:50, Stephen J. Turnbull
<turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
> Nick Coghlan writes:
>
>  > What's not well-defined are the interfaces for calling into
>  > asynchronous code from synchronous code.
>
> I don't understand the relevance to the content of the thread.

Given the schedule_coroutine/run_in_foreground distinction, it's
relatively easy (for a given definition of easy) to write a proxy
object that would make the following work:

    class SomeClass(object):
        def some_sync_method(self):
            return 42
        async def some_async_method(self):
            await asyncio.sleep(3)
            return 42

o = auto_schedule(SomeClass())  # Indicating that the user wants an
async version of the object
r1 = o.some_sync_method() # Automatically run in a background thread
r2 = o.some_async_method() # Automatically scheduled as a coroutine
print(run_in_foreground(r1))
print(run_in_foreground(r2))

It's not particularly useful for an actual event driven server, but it
should be entirely do-able for the purposes of providing a common
interface over blocking and non-blocking APIs.

What it *doesn't* do, and what you need greenlet for, is making that
common interface look like you're using plain old synchronous C
threads.

If folks really want to do that, that's fine - they just need to add
gevent/greenlet as a dependency, just as the folks that don't like the
visibly object-oriented nature of the default unittest and logging
APIs will often opt for third party alternative APIs that share some
of the same underlying infrastructure.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list