At 08:11 PM 3/22/2009 +1200, Greg Ewing wrote: >P.J. Eby wrote: > >>(I'm thus finding it hard to believe there's a non-contrived >>example that's not doing I/O, scheduling, or some other form of >>co-operative multitasking.) > >Have you seen my xml parser example? > >http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/ > >Whether you'll consider it contrived or not I don't know >(contrivedness being such a subjective property) but it >illustrates the style of programming I'm trying to support >with the return-value feature. I find the parser *without* yield-from to be much easier to follow what's going on, actually... and don't see what benefit was obtained by the additional complication of using send(). >>In any case, you didn't address the confusion issue: the inability >>of generators to return a value is there for a good reason, > >It's there because formerly there was nowhere for the >return value to go. If there is somewhere for it to go, >the restriction will no longer be needed. But that's begging the question (in the original meaning of the phrase) of why we *want* to have two ways to return data from a generator. >As for confusion, we ignore the return values of function >calls all the time, without worrying that someone might be >confused by the fact that their return value doesn't go >anywhere. And that's the right way to think of a yield-from >expression -- as a kind of function call, not a kind of yield. But it's not a function call -- it's multiple *inverted* function calls, followed by special handling of the last iteration of the iterator it takes. The control flow is also hard to explain, as is the implementation. >If there's anything confusing, it's the presence of the >word 'yield'. Its only virtue is that it gives a clue that >the construct has something to do with generators, but >you'll have to RTM to find out exactly what. Nobody has >thus far suggested any better name, however. Perhaps this is because it's not that interesting of a feature. As I said, I wouldn't fight a yield-from statement without all this return-value stuff, although it still seems like too much trouble to me.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4