[Python-ideas] Is this PEP-able? for X in ListY while conditionZ:

Andrew Barnert abarnert at yahoo.com
Thu Jun 27 20:26:57 CEST 2013


Sorry for the split reply; hit the wrong button.

On Jun 27, 2013, at 5:19, Nick Coghlan <ncoghlan at gmail.com> wrote:

> If you're willing, I'm actually thinking this may be one of those
> discussions that's worth summarising in a PEP, even if it's just to
> immediately mark it Rejected. Similar to PEP 315 and a few other PEPs,
> it can help to have a document that clearly spells out the objective
> (which I think you summarised nicely as "trying to find a syntactic
> replacement for itertools.takewhile, just as comprehensions replaced
> many uses of map and filter"), even if no acceptable solution has been
> found.

The ideas are pretty broad-ranging. In particular, #1 got two somewhat supportive responses that had nothing to do with the comprehension termination idea. Do side issues like that need to be discussed first/separately before referencing them in a while clause PEP?

Also, we seem pretty far from a consensus on what the actual tradeoffs are for most of the options. For example, is the definition of comps in terms of loops the core idea behind the abstraction, or a minor triviality that's only useful in understanding bad code? Are the differences between comps and genexps a bug or a feature?

Finally, how does this connect up to the original idea of this thread, which was to draft a PEP for while clauses in loop statements rather than in comprehensions? Obviously if that existed, it would change the options for comp syntax. Do we need to include that idea in the discussion? (I completely forgot about it while digging up all of the ideas that spun off from it...)

> That phrasing of the objective also highlights a counter argument I
> hadn't considered before: if we don't consider takewhile a common
> enough use case to make it a builtin, why on *earth* are we even
> discussing the possibility of giving it dedicated syntax?

Besides early termination for comps, the only good use case I know of is in code that already makes heavy use of itertools, and making one of the functions a builtin wouldn't change anything.

And if early termination for comps is a special case, it doesn't seem too unreasonable to consider other ways to handle it.

But you're right that "make takewhile a builtin" should probably be considered among the alternatives.



More information about the Python-ideas mailing list