[Python-ideas] PEP 315: do-while

Stephen J. Turnbull stephen at xemacs.org
Fri Jun 28 08:59:02 CEST 2013


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.




More information about the Python-ideas mailing list