On Thu, Aug 10, 2017 at 1:53 PM, Spencer Brown <spencer...@live.com> wrote:
> The logical solution to me is to allow any order of while and if, and > follow the same 'rule' as multiple for loops - just nest/test those in that > order. > Actually, I think it would be better to only allow one order, and have the "while" always teeted first -- which may mean it should be placed first for clarity. > Then you can have whatever priority you need. One question though is how > this should handle multiple loops - break all of them, or just the current > one? > just the current one, just like a "break", or for that matter, a nested while... -CHB > - Spencer Brown > > On 11 Aug 2017, at 6:27 am, Chris Barker <chris.bar...@noaa.gov> wrote: > > On Thu, Aug 10, 2017 at 8:39 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > > >> Also, there's a potential issue >> here - consider >> >> [expr for var in even_numbers() if is_odd(var) while var < 100] >> >> This is an infinite loop, even though it has a finite termination >> condition (var < 100), because we only test the termination condition >> if var is odd, which it never will be. >> > > why is the termination only tested if teh if clause is True? Could then > not be processed in parallel? or the while first.... > > so maybe better to do: > > [expr for var in even_numbers() while var < 100 if is_odd(var)] > > Maybe it's just me, but I would certainly expect the while to have > precedence. > > I guess I think of it like this: > > "if" is providing a filtering mechanism > > "while" is providing a termination mechanism > > -- is there a use case anyone can think of when they would want the while > to be applied to the list AFTER filtering? > > Obviously, this is a contrived example. And certainly "don't do that, >> then" is a valid response. But my instinct is that people are going to >> get this wrong - *especially* in a maintenance environment. > > > sure, but would there be an issue if teh while were given precedence? > > Overall, I agree with Steven's point. It seems pretty obvious what the >> intention is, and while it's probably possible to construct examples >> that are somewhat unclear, >> >> 1. The mechanical rule gives an explicit meaning >> 2. People shouldn't be writing such complex comprehensions, so if the >> rule doesn't give what they expect, they can always rewrite the code >> with an explicit (and clearer) loop. >> > > me too -- a direct translation to a for loop isn't necessary to understand > how it works. > > -CHB > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/