The Python yield keyword explained • Hacker News Board

Re: The Python yield keyword explained

#51

Post by eru » Wed, Jan 30, 2013, 3:44 PM UTC

csense wrote: post #38

Yttrill wrote: post #29

Earlier quoted context omitted.

This does reflect very sadly on schools, and shows up when trying to explain things to programmers used to conventional languages, especially if you're trying to explain why C is fundamentally broken. Roughly there are three fundamental control transfer operations: conditional jumps, subroutine calls, and coroutine calls. A subroutine is a slave, the caller is a master. With coroutines, the caller and callee are peer…

> Coroutine calling is more fundamental and easier to program Citation needed. For coroutines, each coroutine needs its own stack. That means you have to have a dynamic memory system baked into the language. And maybe garbage collection too. > on today's badly designed CPU's you have to think of coroutines as requiring stack swapping I can't think of an implementation of yield (let alone general coroutines) that does…

> For coroutines, each coroutine needs its own stack. That means you have to have a dynamic memory system baked into the language. And maybe garbage collection too.

Why? Just statically give every co-routine it's own stack.

Re: The Python yield keyword explained

#52

Post by csense » Sun, Feb 03, 2013, 8:33 AM UTC

eru wrote: post #51

csense wrote: post #38

Earlier quoted context omitted.

> Coroutine calling is more fundamental and easier to program Citation needed. For coroutines, each coroutine needs its own stack. That means you have to have a dynamic memory system baked into the language. And maybe garbage collection too. > on today's badly designed CPU's you have to think of coroutines as requiring stack swapping I can't think of an implementation of yield (let alone general coroutines) that does…

> For coroutines, each coroutine needs its own stack. That means you have to have a dynamic memory system baked into the language. And maybe garbage collection too. Why? Just statically give every co-routine it's own stack.

The number of coroutine invocations, and the order in which they're cleaned up, could depend on user input. The former could be unbounded.

More formally, I'm pretty sure you can write a program that always halts, but for every pair of large numbers N, K > 0, there are at least K different input values that result in (1) at least N coroutine invocations being simultaneously active, and (2) for each of those K different input values, those invocations finish in a different order.

Re: The Python yield keyword explained

#53

Post by csense » Sun, Feb 03, 2013, 8:37 AM UTC

eurleif wrote: post #49

gejjaxxita wrote: post #48

Earlier quoted context omitted.

I agree that would be confusing, but I question that early return is needed - I don't think I've ever seen a generator example where early return is used. It could be that it's because I haven't seen enough examples of course. Please share some examples of a generator with early return which can't be accomplished easily and clearly in some other way.

def first10(*iterables): n = 0 for iterable in iterables: for item in iterable: yield item n += 1 if n == 10: return

This is actually a one-liner, because itertools is awesome:

  first10 = lambda iterables : itertools.islice(itertools.chain(*iterables), 0, 10)