On 4 October 2016 at 17:50, Stephen J. Turnbull
<turnbull.stephen...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
