Home Original page

[Python-ideas] Async context managers and iterators with tulip

Antoine Pitrou solipsis at pitrou.net
Sun Dec 23 12:25:58 CET 2012 
On Sun, 23 Dec 2012 12:06:31 +0100
Geert Jansen <geertj at gmail.com> wrote:
> On Sat, Dec 22, 2012 at 10:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> [...]
> > We'd be heading even further down the path of
> > two-languages-for-the-price-of-one if we did that, though (by which I
> > mean the fact that async code and synchronous code exist in parallel
> > universes - one, more familiar one, where the ability to block is
> > assumed, as is the fact that any operation may give concurrent code
> > the chance to execute, and the universe of Twisted, tulip, et al,
> > where possible suspension points are required to be explicitly marked
> > in the function where they occur).
> 
> The two languages/parallel universes (sync and asyc) is a big concern
> IMHO. I looked at a greenlet based program that I'm writing and i'm
> using call stacks that are 10 deep or so. I would need to change all
> these layers from the scheduler down to use yield-from to make my
> program async.
> 
> The higher levels are typically application specific and could decide
> to either be sync or async. For the lower levels (e.g. transports and
> protocols): those are typically library code and you'd need two
> versions. The latter can amount to quite a bit of duplication: there's
> a lot of protocol code currently in the standard library.

Protocols written using a callback style (data_received(), etc.), as
pointed by Laurens, can be used with both blocking and non-blocking
coding styles. Only the transports would need to be duplicated, but
that's expected.

Regards

Antoine.
More information about the Python-ideas mailing list