5 ms·
> But very briefly, yield in Python is often presented as a simplified method for writing generators, but what it does, suspending the execution of a function w
by intrepidhero 5y ago
> But very briefly, yield in Python is often presented as a simplified method for writing generators, but what it does, suspending the execution of a function with the ability to resume it, is a much general concept than iteration. It enable a routine to do a small amount of work, and then pass the control to another routine, thus allowing them to run concurrently.
I don't think that is what concurrently means. Generators allow interleaved execution or lazy evaluation. In fact the author makes this point further down so I think the above sentence was just a slip of the pen. But I point it out because that very misunderstanding is one that tripped me up for a time.
> More accurately, yield in a function creates a generator, which suspends its execution at the point where yield appears in the definition.
That's better.
- vanderZwan 5y agoSo what do you think concurrently means? For the record, the quoted explanation you disagree with fits Esterel and other data-flow languages perfectly, and nobody will deny that they are (synchronous) concurrent languages.
- intrepidhero 5y agoI thought it meant that two streams of instructions could be executed simultaneously. I thought it meant I needed to start worrying about shared/private memory and locks and things. Python's generators are handy for in that kind of program but not necessary. But it sounds like from the replies I was wrong.
- vanderZwan 5y agoAh, so a variation of the classic "concurrency vs paralellism" misconception. In your defense: it's considered a classic misconception for a reason, so I wouldn't feel to bad about it :)
- jtsiskin 5y agoYou are thinking of “parallel”. This is a fine usage of concurrent.
- chowells 5y agoSeems like the standard definition of concurrent to me. Concurrency is a programming model, not an execution model. It means writing multiple pieces of code in a simple linear model that can have their execution interleaved with execution of other code. The primary contrast is managing a complex state machine by hand. coughNodecough Given that concurrency is often implemented with a state machine, the difference is not what happens at run time. The difference is the programming model used. Parallel execution is a fully separate matter.
- intrepidhero 5y agoThat's really interesting. Perhaps the gap in my knowledge is the difference between programming model and execution model. But let me ask another question: What's the difference between yielding from a function and returning? Why is yielding considered concurrent programming and returning sequential? I guess I had associated concurrent programming with threads but maybe multi-threaded programming is better called parallel execution?
- Jtsummers 5y agoReturn terminates the function or thread of execution. Yield (may) provides a value but leaves the thread of execution alone otherwise, only pausing it. It’s resumable where a return is not (without a lot of extra bookkeeping). https://blog.golang.org/waza-talk https://blog.golang.org/waza-talk A good talk that expresses the current sentiment and helped establish it. Concurrency may be parallel, but doesn’t need to be. This does go against the common (outside programming) notion of the meaning of concurrent which means it provides a strong potential for confusion.
- gpderetta 5y agoEquivalently, both yield and return invoke the calling function continuation, but while return discards the current one, yield saves it somewhere for resumption.
- simiones 5y ago
- butterisgood 5y agoI would say concurrency is more of a way of organizing code into independent parts. If you have multiple contexts, logically separable, and they can execute independently you end up with some form of concurrent design. The reason people often think of coroutines (like generators resuming) vs routines (functions) as concurrent vs not concurrent has everything to do with contexts that can be thought of as executing in a non-deterministic order. Certainly there might be external dependencies that "force" an ordering to execution, but at the end of the day, it's the independence of an operation/computation that makes it concurrent with another. Concurrency can give rise to opportunities for things to execute in parallel, but it does not require them. Parallelism is therefore a condition of execution/evaluation. On a uniprocessor unix kernel, processes execute concurrently. On a multiproccessor unix kernel, you hope for parallel execution of processes (though they may be totally unrelated in context or goal), but you always maintain the concurrency. The scheduler pauses and switches contexts. The ability to switch contexts seems fairly equivalent to concurrency. And I don't think much else is needed. I'm not sure that's 100% correct, but it's how I like to think of this situation.