Hacker News Reader

Comment by davidhollander | Hacker News Reader

Using Python generators for real work... or why I switched to Lua.

They're great at first, but then let's say you need to subdivide pieces of the generator into helper functions for better organization. Or yield recursively. Turns out you can't, because yielding is A) syntactical and B) can only be done from the main function body.

It took us until Python 3 to replace "print x" with a more sensical, functional "print(x)". Yet for yield we are stuck with even worse arbitrary syntactical rules for "yield x", instead of being able to do "yield(x)" where it yields to the wrapping generator\coroutine from wherever it is in a call stack. The result is nonintuitive, less-refactorable code.

http://lua-users.org/wiki/LuaCoroutinesVersusPythonGenerator...

View on HN

Actually, Python generators will be changing quite a bit soon: http://www.python.org/dev/peps/pep-0380/

Thanks for the link, I had not read 0380.

The proposed solution seems to be increasing syntactic complexity rather than reducing it by adding another keyword, "from" into the mix which is hardly optimal imo.

This to me indicates a systematic logical flaw of thinking of hitting a "yield" in the call stack as analagous to "return". When in fact it is the inverse and analagous to waiting for a function to return and thus more similar to a print() function call. The whole point of coroutine yielding is that it inverts the point of view of a call stack and allows the called routine to be the calling routine as well.

I still use Python for some things and have too many fond memories to ever hate it, but even if generators get cleaned up I'll probably stay w/ Lua for pipeline type projects as I've grown too used to runtime within an order of magnitude of C, better coroutines, and its more Scheme-like nature.

My interpretation of the "yield" keyword is not that of a coroutine yield, but that of "cough up the following value", which is more in line with "return". Under that interpretation, the fact that generators can also be used to implement coroutines is a coincidence with unfortunate terminology namespace conflicts.

I looked around a bit for the original semantic intention behind choosing "yield" as a keyword, but came up empty. Anyone?

It is my understanding "yield" refers to "execution control". If semantic meaning is of concern over lexical, let us ignore the names "coroutine" and "generator" and focus on the general logic of code continuation. That is, the difference between pausing the current execution context vs destroying it.

Function call: halt further processing of current call stack, execute procedures, resume call stack after function call when control returns.

Yield: halt further processing of current call stack, execute procedures, resume call stack after yield when control returns.

Return: destroy current call stack.

The variation present on the code continuation axis is far more significant than the variation on the coughing-up-values axis.

I think, in this case, 'yield' is being used less in the sense of a street sign, and more in the sense of crop yield.

agreed, that's a significant pain point. That's also why I think using yield as "syntactic sugar" for asynchronous programming is a good looking but bad idea. It makes refactoring async code using yield even harder than it already is.

You could use eventlet or gevent for coroutines in Python.

Reply on news.ycombinator.com