I'm personally think that `a` prefix is pretty fine and understandable. Do we really need to implement full PEP-342 spec in async way? What are use cases? My first thought is PEP-255-like simple async generators should be enough.
Full PEP-342 styled generators are clue for implementing things like twisted.inlineCallback and tornado.gen. Thanks to PEP-492 we don't need it anymore. All my requirements are covered perfectly fine by existing `__aiter__`/`__anext__`. What I really need is allowing to write just `yield val` from coroutine but never need for `resp = yield req` On Fri, Jul 29, 2016 at 8:50 PM Yarko Tymciurak <yark...@gmail.com> wrote: > > > 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> 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/ -- Thanks, Andrew Svetlov
_______________________________________________ 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/
