yield_all needed in Python
nessus at mit.edu
Tue Mar 1 19:22:22 CET 2005
Duncan Booth <duncan.booth at invalid.invalid> writes:
> Douglas Alan wrote:
>> "Terry Reedy" <tjreedy at udel.edu> writes:
>>> Cetainly, if <yield_all
>>> iterator> == <for i in iterator: yield i>, I don't see how anything
>>> is gained except for a few keystrokes.
>> What's gained is making one's code more readable and maintainable,
>> which is the one of the primary reasons that I use Python.
> On of the reasons why Python is readable is that the core language is
> comparatively small.
It's not that small anymore. What it *is* is relatively conceptually
simple and readily comprehensible (i.e. "lightweight"), unlike
languages like C++ and Perl.
> Adding a new reserved word simply to save a few
It's not to "save a few characters". It's to make it immediately
clear what is happening.
> is a difficult choice, and each case has to be judged on its merits,
> but it seems to me that in this case the extra syntax is a burden
> that would have to be learned by all Python programmers with very
> little benefit.
The amount of effort to learn what "yield_all" does compared to the
amount of effort to understand generators in general is so miniscule,
as to be negligible. Besides, by this argument, the standard library
should be kept as small as possible too, since people have to learn
all that stuff in order to understand someone else's code.
> Remember that many generators will want to do slightly more than just yield
> from another iterator, and the for loop allows you to put in additional
> processing easily whereas 'yield_all' has very limited application e.g.
> for tok in tokenstream():
> if tok.type != COMMENT:
> yield tok
> I just scanned a random collection of my Python files: out of 50 yield
> statements I found only 3 which could be rewritten using yield_all.
For me, it's a matter of providing the ability to implement
subroutines elegantly within generators. Without yield_all, it is not
elegent at all to use subroutines to do some of the yielding, since
the calls to the subroutines are complex, verbose statements, rather
than simple ones.
I vote for the ability to have elegant, readable subroutining,
regardless of how much you in particular would use it.
More information about the Python-list