On Tue, May 5, 2015 at 2:01 PM, Paul Moore <p.f.mo...@gmail.com> wrote:
> On 5 May 2015 at 21:00, Yury Selivanov <yselivanov...@gmail.com> wrote: > > On 2015-05-05 3:40 PM, Jim J. Jewett wrote: > >> > >> On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated > PEP492. > >> > >> Where are the following over-simplifications wrong? > >> > >> (1) The PEP is intended for use (almost exclusively) with > >> asychronous IO and a scheduler such as the asynchio event loop. > > > > Yes. You can also use it for UI loops. Basically, anything > > that can call your code asynchronously. > > Given that the stdlib doesn't provide an example of such a UI loop, > what would a 3rd party module need to implement to provide such a > thing? Can any of the non-IO related parts of asyncio be reused for > the purpose, or must the 3rd party module implement everything from > scratch? > > To me, this is an important question, as it cuts directly to the heart > of the impression people have that coroutines and async are "only for > asyncio". > > I'd be interested in writing, for instructional purposes, a toy but > complete event loop. But I'm *not* really interested in trying to > reverse engineer the required interface. > This is a great idea. What kind of application do you have in mind? I think the main real-life use case for using coroutines with a UI event loop is newer Windows code. C# (and IIUC VB) has coroutines very much along the lines of PEP 492, and all code that does any kind of I/O (whether disk or network) must be written as a coroutine. This requirement is enforced by the C# compiler: the basic system calls for doing I/O are coroutines, and in order to get their result you must use an await expression, which in turn may only be used in a coroutine. Thus all code that may invoke an I/O call ends up being a coroutine. This is exactly the type of constraint we're trying to introduce into Python with PEP 492 (except of course we're not making all I/O primitives coroutines -- that would be madness, we're going with optional instead). -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
