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

[jimjhb at aol.com]

-----Original Message-----
From: Andrew Barnert <abarnert at yahoo.com>
To: Nick Coghlan <ncoghlan at gmail.com>
Cc: python-ideas <python-ideas at python.org>
Sent: Thu, Jun 27, 2013 2:28 pm
Subject: Re: [Python-ideas] Is this PEP-able? for X in ListY while conditionZ:


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.
=====================
So combining this and what Shane says, "trying to find a syntactic replacement for itertools.takewhile, just as comprehensions replaced many uses of map and filter", which is also usable in comprehensions?  (Maybe that was already implied)
You should probably include the Wolfgang Maier thread in Jan. 2013 on the same subject.



_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
http://mail.python.org/mailman/listinfo/python-ideas

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130627/46a4f2aa/attachment.html>