Comments inlined:


> On Jul 29, 2016, at 2:20 PM, Yarko Tymciurak <yarkot1@gmail.com> 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