Shane Green writes:
List comprehensions are concise, intuitive, and efficient; proper use can improve readability *and* performance significantly.
Truth, the whole truth, and nothing but the truth.
The number of proper applications is limited by list comprehension limitations.
Truth, but not the whole truth.
Adding the ability to configure termination in the comprehension will increase that number.
Not necessarily. In fact, any programming construct is limited by *human* comprehension limitations. As has been pointed out by people who think about these issues deeply and push these constructs to their limits, *because* a comprehension[1] is an *expression*, nested comprehensions (nested in higher-level expressions) are possible. Adding clauses to the construct increases the complexity, and comprehensions are already pretty complex.[2] Personally, *because* iterables can be infinite, I think the lack of a stop clause in comprehensions is ugly and adds some unobvious complexity to comprehensions and displays. The programmer needs to also keep in mind the possibility that some iterables are infinite, and deal with that. The convenience value of an internal "takewhile()" is also undeniable. I'd like to see the feature added. But I definitely see this as a tradeoff, and I don't know how costly the increased complexity of comprehensions would be to folks who push the limits of comprehension usage already. Increased complexity in the basic construct might push them over the limit, and they would *decrease* usage.[3] Nick et al clearly are concerned about that end of the spectrum, and I personally would place those needs over mine in this case. (YMMV, that's just my opinion about *me*.) Footnotes: [1] Here and below "comprehension" includes generators and displays that take arbitrary iterables. [2] As an objectively verifiable measure (probably pretty imperfect, but relatively objective) of that complexity, at present a fully elaborated comprehension looks like [ # we have a comprehension function(x) # we need to know what function does for x # loop variable we need to track in iterable # we need to know what iterable generates if # optional so need to track "dangling if" condition(x) # we need to know what satisfies condition ] So a comprehension necessarily requires a minimum of 5 facts (each comment describes a fact), sometimes 6, and context (iterable = nested comprehension, etc) will usually add more. So most comprehensions are already at the median of the "7 plus/minus 2" facts that psychologists say that typical humans can operate on simultaneously. Adding another optional clause puts it close to the upper bound of 9, even before considering context and nested comprehensions. [3] True, if such a person is designing from scratch, they can simply make a rule of thumb to avoid the new takewhile feature when they're going to have complex nested comprehensions. But if they're maintaining existing code that already uses the feature, that rule of thumb might cause them to eschew the more extensive changes required to convert to a concise expression in terms of nested comprehensions, or similar.