On Sat, Oct 20, 2012 at 1:55 PM, Christian Tismer wrote:

Clarification:

I have a tendency to mention constructs from other threads in a discussion. This might suggest that I'm propose using this not-yet-included or even accepted feature as a solution. For instance Guido's reaction to my last message might be an indicator of misinterpreting this, although I'm not sure if I was Prinarily addressed at all (despite that the to/cc suggested it).

Anyway, I just want to make sure:

If I'm mentioning stackless or codef or greenlet, this does not imply that I propose to code the solution to async by implementing such a thing, first. The opposite is true.

I mean such meantioning more like a macro-like feature: I'm implementing structures using the existing things, but adhere to a coding style that stays compatible to one of the mentioned principles.

This is like a macro feature of my brain - I talk about codef, but code it using yield-from.

So please don't take me wrong that I want to push for features to be included. This is only virtual. I use yield constructs, but obey the codef protocol, for instance.

And as an addition: when I'm talking of generators implemented by yield from, then this is just a generator that can yield from any of its sub-functions.

I am not talking about tasks or schedulars. These constructs do not belong there. I'm strongly against using "yield from" for this. It is a building block for generatos resp. coroutines, and there it stops !

Higher level stuff should by no means use those primitives at all.

Ok, understood, and sorry if I mistook your intention before. Here's how I tend to use some terminology: - generator function: any function containing yield - generator object: the iterator returned by calling a generator function - generator: either of the above, when the context makes it clear which one I mean, or when it doesn't matter - iterator generator: a generator used to produce values that one would consume with an implicit or explicit for-loop - coroutine: a generator function used to implement an async computation instead of an iterator - Future: something with roughly the interface but not necessarily the implementation of PEP 3148 - Deferred: the Twisted Deferred class or something with similar functionality (there are some in the JavaScript world) Note that I use coroutine for both PEP-342-style and PEP-380-style generators (i.e. "yield <future>" vs. "yield from <generator>"). The big difference between Futures and Deferreds is that Deferreds can easily be chains together to create multiple stages, and each callback is called with the value returned from the previous stage; also, Deferreds have separate callback chains for regular values and errors.

Sent from my Ei4Steve

Does it happen to have a 40-char wide screen? :-) -- --Guido van Rossum (python.org/~guido)