Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Neil Cerutti <neilc@norwich.edu>
Newsgroups: comp.lang.python
Subject: Re: attaching names to subexpressions
Date: 29 Oct 2012 11:53:52 GMT
Organization: Norwich University
Lines: 35
Message-ID: <af792fF490mU2@mid.individual.net>
References: <a533d812-480e-479b-9210-7097c2d70d73@a4g2000pbo.googlegroups.com> <mailman.2934.1351343030.27098.python-list@python.org> <508c810f$0$29967$c3e8da3$5496439d@news.astraweb.com> <mailman.2950.1351403908.27098.python-list@python.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: individual.net 38TYHtcH592quflJeM7g1goCtJqGabIdq61TBVA1JWG7MSJ2H6K8UBmYJ0c3JILITd
Cancel-Lock: sha1:vHU70lc8HsYGZZuFE/1C94RSKEk=
User-Agent: slrn/0.9.9p1/mm/ao (Win32)
Xref: csiph.com comp.lang.python:32362

On 2012-10-28, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
>>> The 'canonical way'
>>> while True:
>>>      line = complex_expression
>>>      if not line:
>>>          break
>>>      do_something_with(line)
>>>
>>> avoids this problem, but I was never really convinced about the beauty /
>>> readbility of this construct.
>>>
>>> In
>>> my opinion I shouldn't be obliged to read any of the indented lines of
>>> the while statement on a first 'visual' pass through somebody elses code
>>> and still be able to see what the loop iterates through.
>>
>> Fine. Then write your code as:
>>
>> line = function(x, y, z)
>> while line:
>>      do something with(line)
>>      line = function(x, y, z)
>
> We have a problem, and two solutions. Solution 1 has downside
> A, and solution 2 has downside B. If he complains about
> downside A, you say, well, use solution 2. If he complains
> about downside B, you say, well, use solution 1.
>
> What if he wants to avoid both downsides A and B? What solution
> does he use then?

You abandon the while loop and compose a generator.

-- 
Neil Cerutti