[Async-sig] PEP: asynchronous generators

[Yarko Tymciurak]

On Friday, July 29, 2016, Yury Selivanov <yselivanov at gmail.com> wrote:

> Comments inlined:
>
>
> > On Jul 29, 2016, at 2:20 PM, Yarko Tymciurak <yarkot1 at gmail.com
> <javascript:;>> wrote:
> >
> > Hmm...  I think we need to think about a future where, programmatically,
> there's little-to no distinction between async and synchronous functions.
> Pushing this down deeper in the system is the way to go. For one, it will
> serve simple multi-core use once gilectomy is completed (it, or something
> effectively equivalent will complete).  For another, this is the path to
> reducing the functionally "useless" rewrite efforts of libraries (e.g.
> github.com/aio-libs), which somehow resemble all the efforts of migrating
> libraries from 2-3 (loosely).  The resistance and unexpected time that 2-3
> migration experienced won't readily be mimicked in async tasks - too much
> effort to get computer and I/O bound benefits?  Maintain two versions of
> needed libraries, or jump languages is what will increasingly happen in the
> distributed (and more so IOT) world.
>
> When and *if* gilectomy is completed (or another project to remove the
> GIL), we will be able to do this:
>
> 1) Run existing async/await applications as is, but instead of running a
> process per core, we will be able to run a single process with many
> threads.  Likely one asyncio (or other) event loop per thread.  This is
> very speculative, but possible in theory.
>
> 2) Run existing blocking IO applications in several threads in one
> process.  This is something that only sounds like an easy thing to do, I
> suspect that a lot of code will break (or dead lock) when the GIL is
> removed.  Even if everything works perfectly well, threads aren’t answer to
> all problems — try to manage 1000s of them.
>
> Long story short, even if we had no GIL at all, having async/await (and
> non-blocking IO) would make sense.  And if you have async/await, with GIL
> or without, you will inevitably have different APIs and different IO
> low-level libs that drive them.
>
> There are ways to lessen the pain.  For instance, I like Cory’s approach
> with hyper - implement protocols separately from IO, so that it’s easy to
> port them to various sync and async frameworks.
>
> >
> > Time to think about paving the way to async-as first class citizen world.
> >
> > That's probably too much for this PEP, but the topic (a- prefixing) is a
> good canary for the bigger picture we need to start mulling over.
> >
> > So in this context (and in general w/ async) asking the question "can we
> make it so it doesn't matter?" is a good one to always be asking - it will
> get is there.
> >
>
> Unfortunately there is no way to use the same APIs for both async/await
> and synchronous world.  At least for CPython builtin types they have to
> have different names.
>
> I’m fine to discuss the ‘a’ prefix, but I’m a bit afraid that focusing on
> it too much will distract us from the PEP and details of it that really
> matter.
>
> Yury


To keep it simple, try thinking like this (and yes, Yury, apologies - this
is now a side discussion, and not about this pep):  everything in CPython
is async, and if you don't want async, you don't need to know about, you
run a single async task and don't need to know more...

Can we get there?
That would be cool...

- Yarko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160729/1cf4c4d2/attachment.html>