On Friday, July 29, 2016, Yury Selivanov <yseliva...@gmail.com> wrote:
> Comments inlined: > > > > On Jul 29, 2016, at 2:20 PM, Yarko Tymciurak <yark...@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
_______________________________________________ Async-sig mailing list Async-sig@python.org https://mail.python.org/mailman/listinfo/async-sig Code of Conduct: https://www.python.org/psf/codeofconduct/
