Re: Is this PEP-able? fwhile
On 26.06.2013 16:28, William Ray Wing wrote: On Jun 26, 2013, at 7:49 AM, Fábio Santos mailto:fabiosantos...@gmail.com>> wrote: On 26 Jun 2013 11:45, mailto:jim...@aol.com>> wrote: > > On Tuesday, June 25, 2013 9:30:54 PM UTC+5:30, Ian wrote: > > In my experience the sorts of people who preach "one exit point" are > > also all about defining preconditions and postconditions and proving > > that the postconditions follow from the preconditions. I think that > > the two are linked, because the "one exit point" rule makes those > > sorts of proofs simpler. > > Ah! utopia! > > For every one who knows about pre/post/invariant conditions, there are 10 who follow goto-statement-is-harmful like a religious edict. > > > > I just checked and MISRA-C 2012 now allows gotos in specific, limited circumstances. I think it was the MISRA-C 1998 standard that caused all this trouble. So if MISRA now allows goto, why not Python :) > What is the matter? Just use the goto module... Wondered when that would be mentioned. Personally, I've never found that much use for GoTo, but as old timers know, that same module adds the Come_From entry point, which is priceless. ;-) Bill Actually, jumping to any place a program (I know it from QBasic :) ) is some kind of voodoo. At first it seems that any function calling itself or calling another function from another function solves the "goto" puzzle - called OO programming, objects in space and inheritance? But at 2nd glimpse, jumping in any place of code (function) or routine, at a given place precisely - and to avoid any checks and unrelated code which might occur on a regular function call and without the need to provide additional arguments - that's kinda cool (if variables are in scope by the target statements :) ) That's somehow how I remember it. But I guess if everything should run as in a factory, one entrance, one component, one result and independently from each other (isolated) and on many cores and such, a goto without argument passing or state variables might just end up in a big mess. What do you think? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
Dennis Lee Bieber wrote: > On Mon, 24 Jun 2013 19:01:11 -0700 (PDT), rusi > declaimed the following: > >>On Tuesday, June 25, 2013 3:08:57 AM UTC+5:30, Chris Angelico wrote: >>> On Tue, Jun 25, 2013 at 5:52 AM, <> wrote: >>> >>> > (NOTE: Many people are being taught to avoid 'break' and 'continue' at >>> > all >>> > costs... >>> >>> Why? Why on earth should break/continue be avoided? >> >>Because breaks and continues are just goto-in-disguise? >> >Because GOTO is a wild-card, capable of redirecting to anywhere; > whereas break can only go to the exit of the loop (and in languages with > labeled loops, possibly the exit of an outermost loop -- cf: Ada), and > continue can only go to the next iteration of the loop (hmmm, does any > language have a continue that can go to the next iteration of an outer > loop?) Bash: continue: continue [n] Resume for, while, or until loops. Resumes the next iteration of the enclosing FOR, WHILE or UNTIL loop. If N is specified, resumes the Nth enclosing loop. Jerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Jun 26, 2013, at 7:49 AM, Fábio Santos wrote: > On 26 Jun 2013 11:45, wrote: > > > > On Tuesday, June 25, 2013 9:30:54 PM UTC+5:30, Ian wrote: > > > In my experience the sorts of people who preach "one exit point" are > > > also all about defining preconditions and postconditions and proving > > > that the postconditions follow from the preconditions. I think that > > > the two are linked, because the "one exit point" rule makes those > > > sorts of proofs simpler. > > > > Ah! utopia! > > > > For every one who knows about pre/post/invariant conditions, there are 10 > > who follow goto-statement-is-harmful like a religious edict. > > > > > > > > I just checked and MISRA-C 2012 now allows gotos in specific, limited > > circumstances. I think it was the MISRA-C 1998 standard that caused all > > this trouble. So if MISRA now allows goto, why not Python :) > > > > What is the matter? Just use the goto module... > > Wondered when that would be mentioned. Personally, I've never found that much use for GoTo, but as old timers know, that same module adds the Come_From entry point, which is priceless. ;-) Bill-- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tuesday, June 25, 2013 10:09:53 PM UTC+5:30, jim...@aol.com wrote: > I just checked and MISRA-C 2012 now allows gotos in specific, limited > circumstances. I think it was the MISRA-C 1998 standard that caused all this > trouble. So if MISRA now allows goto, why not Python :) Not sure who is joking and who serious in this thread. As for who started the 'goto-trouble' it was 30 years before 1998 http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Wednesday, June 26, 2013 6:03:39 PM UTC+5:30, Steven D'Aprano wrote: > On Tue, 25 Jun 2013 12:39:53 -0400, jimjhb wrote: > > > > > I just checked and MISRA-C 2012 now allows gotos in specific, limited > > > circumstances. I think it was the MISRA-C 1998 standard that caused all > > > this trouble. So if MISRA now allows goto, why not Python :) > > > > [humour] > You can! Just use the goto module. It supports both GOTO and COMEFROM: > [/humour] Comefrom + inverted inheritance ! Are we ready for a new pep? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 2013-06-25, rusi wrote: > On Tuesday, June 25, 2013 9:30:54 PM UTC+5:30, Ian wrote: >> In my experience the sorts of people who preach "one exit point" are >> also all about defining preconditions and postconditions and proving >> that the postconditions follow from the preconditions. I think that >> the two are linked, because the "one exit point" rule makes those >> sorts of proofs simpler. > > Ah! utopia! > > For every one who knows about pre/post/invariant conditions, > there are 10 who follow goto-statement-is-harmful like a > religious edict. The one-exit-point rule is helpful for tracking entry and exit invariants. But in my view it shouldn't be followed when it makes code worse. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tue, 25 Jun 2013 12:39:53 -0400, jimjhb wrote: > I just checked and MISRA-C 2012 now allows gotos in specific, limited > circumstances. I think it was the MISRA-C 1998 standard that caused all > this trouble. So if MISRA now allows goto, why not Python :) [humour] You can! Just use the goto module. It supports both GOTO and COMEFROM: http://entrian.com/goto/ [/humour] But seriously... GOTO works best in low-level languages. It is not very well suited for high-level languages like Python. Nevertheless, Python does support a very limited number of flow control statements which are like GOTO in some ways: `break` and `continue` for jumping out of loops, and exceptions which are cheap enough to be used as flow control. You cannot jump into the middle of a function, or to an arbitrary line, or into a loop. But this is a good thing -- languages that allow unrestricted flow control end up with unmaintainable spaghetti code. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 26 Jun 2013 11:45, wrote: > > On Tuesday, June 25, 2013 9:30:54 PM UTC+5:30, Ian wrote: > > In my experience the sorts of people who preach "one exit point" are > > also all about defining preconditions and postconditions and proving > > that the postconditions follow from the preconditions. I think that > > the two are linked, because the "one exit point" rule makes those > > sorts of proofs simpler. > > Ah! utopia! > > For every one who knows about pre/post/invariant conditions, there are 10 who follow goto-statement-is-harmful like a religious edict. > > > > I just checked and MISRA-C 2012 now allows gotos in specific, limited circumstances. I think it was the MISRA-C 1998 standard that caused all this trouble. So if MISRA now allows goto, why not Python :) > What is the matter? Just use the goto module... -- http://mail.python.org/mailman/listinfo/python-list
Is this PEP-able? fwhile
On Tuesday, June 25, 2013 9:30:54 PM UTC+5:30, Ian wrote: > In my experience the sorts of people who preach "one exit point" are > also all about defining preconditions and postconditions and proving > that the postconditions follow from the preconditions. I think that > the two are linked, because the "one exit point" rule makes those > sorts of proofs simpler. Ah! utopia! For every one who knows about pre/post/invariant conditions, there are 10 who follow goto-statement-is-harmful like a religious edict. I just checked and MISRA-C 2012 now allows gotos in specific, limited circumstances. I think it was the MISRA-C 1998 standard that caused all this trouble. So if MISRA now allows goto, why not Python :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Wednesday, 26 June 2013 01:40:22 UTC+1, Dennis Lee Bieber wrote:
> (hmmm, does any
> language have a continue that can go to the next iteration of an outer
> loop?)
Perl allows next with a label:
> perldoc -f next
next LABEL
nextThe "next" command is like the "continue" statement in C; it
starts the next iteration of the loop:
LINE: while () {
next LINE if /^#/; # discard comments
#...
}
Note that if there were a "continue" block on the above, it
would get executed even on discarded lines. If the LABEL is
omitted, the command refers to the innermost enclosing loop.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Wed, Jun 26, 2013 at 10:47 AM, Dennis Lee Bieber wrote: > On Tue, 25 Jun 2013 17:20:43 +1000, Neil Hodgson > declaimed the following: > >>jim...@aol.com: >> >>> Syntax: >>> fwhile X in ListY and conditionZ: >> >>There is precedent in Algol 68: >> >>for i from 0 to n while safe(i) do .. od >> > The REXX variant would be > > do for i = 0 to n while safe(i) > ... > end > > Basically one has an optional "for" clause ( for index = initial to > end > by step ), and one has an optional while/until clause -- Hmm, wonder if > some interpreters would parse both while and until . I need to install > Regina Rexx on this new machine... Modulo the 'for' keyword, which is superfluous there. Here's a test script I knocked up on my OS/2 box back home: /* */ do i=0 to 9 while safe(i) say i" is safe" end exit safe: procedure return arg(1)\=6 The \= in the last line is the REXX "not-equal" operator, like != in Python. This outputs: 0 is safe 1 is safe 2 is safe 3 is safe 4 is safe 5 is safe and then terminates. It's pretty clean; the DO/END construct defines a block, and may optionally execute it more than once. With no arguments, it just creates a block that executes once (equivalent to C's braces); valid args include FOREVER (infinitely loop), WHILE condition (iterate while condition is true), UNTIL condition (execute once, then check condition, iterate while condition is false - like a do/while in C), var=value (eg "I=1" - set var to value, then increment by 1 or by the "BY" value, continue forever or until the "TO" value), and possibly another that's slipped my mind. Aside from FOREVER, which stands alone, they're completely independent. But that's syntax, lots of it. What I'd like to see in Python is simply a bit of flexibility in the rule about newlines. The for/if construct in Python could be exactly the same as it now is, only with the two statements on one line, and it would look very similar to the existing notation. I can already one-line a simple statement: for i in range(10): print(i) I just can't put in an if: >>> for i in range(10): if i%3: print(i) SyntaxError: invalid syntax But I can, as long as I use expression-if: >>> for i in range(10): print(i) if i%3 else None Seriously, I can use Perl-style notation to achieve this. Does that seem right to you? *boggle* ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tuesday, June 25, 2013 9:30:54 PM UTC+5:30, Ian wrote: > In my experience the sorts of people who preach "one exit point" are > also all about defining preconditions and postconditions and proving > that the postconditions follow from the preconditions. I think that > the two are linked, because the "one exit point" rule makes those > sorts of proofs simpler. Ah! utopia! For every one who knows about pre/post/invariant conditions, there are 10 who follow goto-statement-is-harmful like a religious edict. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tue, Jun 25, 2013 at 1:21 AM, Chris Angelico wrote: > On Tue, Jun 25, 2013 at 2:20 PM, Benjamin Kaplan > wrote: >> The reason I was given (which I promptly ignored, of course) is that >> it's "best practice" to only have one exit point for a block of code. >> Only one way of terminating your loop, only one "return" per function, >> never use exceptions, etc. I think it originally came about as a way >> to make sure that your clean-up code was called (and to make it easier >> for code reviewers to make sure your clean up code was called) and >> then started being passed around as a rule among programming teachers >> who didn't have any experience outside the classroom. > > I've heard that "one exit point" rule before, too, but never any > justification for it. Your explanation does at least make sense > (albeit only in a language without even RAII), but I don't like silly > rules like that :) In my experience the sorts of people who preach "one exit point" are also all about defining preconditions and postconditions and proving that the postconditions follow from the preconditions. I think that the two are linked, because the "one exit point" rule makes those sorts of proofs simpler. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 2:33 PM, wrote: > Ian, > > Regarding your first message breaks are anathema (for many) and your other > alternative is complicated. > > Regarding your second post, anding of lists is allowed, but generally > returns non-utile results, but point taken. > I guess technically it could be the last statement, with the condition just > being ListD in your example. To make > the condition more complex (in your example) you'd have to add parens. I'd probably have gone with the first "and". The condition is more likely to use ands than the iterable, and also I expect it would be easier to parse with the simple rule that the first "and" divides it. The ambiguity is nonetheless a black mark against the syntax. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 6/25/2013 7:17 AM, jim...@aol.com wrote: for i in range(n) while safe(i): .. Combined for-while and for-if statements have been proposed before and rejected. We cannot continuously add simple compositions to the langauge. I disagree. The problem IMO is that python 'for's are a different kind of 'for' in that they have no explicit indexing and no explicit range test; just a list which has elements drawn from it. This is amazingly powerful and concise. Unfortunately, the "breaks are just gotos" community often ruins this conciseness by going to 'while' or itertools (or worse) to avoid adding a break to a 'for' which needs to be terminated early. 'Break' and 'continue' were intended to be used ;-). I think suggestions like yours and Fabio's are good ones. If 'for' has an 'else', why not a 'while'? While-else and for-else follow from if-else. Which is to say, the else corresponds to the buried if that is part of while and for. The else part triggers when the if part is false. The difference from if-else is that the if part is tested multiple times. while condition(): block() else: finish() is equivalent to while True: if condition(): block() continue else: finish() break -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Is this PEP-able? fwhile
Ian, Regarding your first message breaks are anathema (for many) and your other alternative is complicated. Regarding your second post, anding of lists is allowed, but generally returns non-utile results, but point taken. I guess technically it could be the last statement, with the condition just being ListD in your example. To make the condition more complex (in your example) you'd have to add parens. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 11:45:57PM +0100, MRAB wrote: > On 24/06/2013 23:35, Chris Angelico wrote: > >On Tue, Jun 25, 2013 at 8:30 AM, Tim Chase > > wrote: > >>On 2013-06-25 07:38, Chris Angelico wrote: > >>>Python has no issues with breaking out of loops, and even has > >>>syntax specifically to complement it (the 'else:' clause). Use > >>>break/continue when appropriate. > >> > >>from minor_gripes import breaking_out_of_nested_loops_to_top_level > > > >True. There are times I do wish for a 'goto'. But if goto were > >implemented, I would also use it for jumping _into_ loops, and I'm not > >sure that's going to make the feature popular :) > > > I think a better way would be to label the outer loop somehow and then > break out of it by name. Would say that procedure-scoped gotos are useful for more than manipulating loops indeed. Doubt if either will be in Python ever though. -- Göktuğ Kayaalp -- http://mail.python.org/mailman/listinfo/python-list
Is this PEP-able? fwhile
> Syntax: > fwhile X in ListY and conditionZ: There is precedent in Algol 68: for i from 0 to n while safe(i) do .. od which would also make a python proposal that needs no new key words: for i in range(n) while safe(i): .. The benefit of the syntax would be to concentrate the code expressing the domain of the loop rather than have it in separate locations. Not a big win in my opinion. Neil Neil, I disagree. The problem IMO is that python 'for's are a different kind of 'for' in that they have no explicit indexing and no explicit range test; just a list which has elements drawn from it. This is amazingly powerful and concise. Unfortunately, the "breaks are just gotos" community often ruins this conciseness by going to 'while' or itertools (or worse) to avoid adding a break to a 'for' which needs to be terminated early. I think suggestions like yours and Fabio's are good ones. If 'for' has an 'else', why not a 'while'? FWIW, I can sympathize with the 'no breaks or continues' notion, at least largely so. That said, I have used gotos sparingly in C. The problem is that applying the no-breaks notion to the python 'for' is problematic because as I said earlier, the python 'for' is a special kind of 'for'. Maybe Guido needs to be seen in public hugging a break statement. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 24 June 2013 23:50, Chris Angelico wrote: > > In more free-form languages, I implement this by simply omitting a line-break: ... > Python could afford to lose a little rigidity here rather than gain > actual new syntax: > > for i in range(10): if i%3: > print(i) > > And there you are, the for-if "filtered iteration" model, just by > relaxing one rule. Maybe rather: for i in range(10); if i%3: print(i) One of the awesomer things about Coffeescript is: decorator = (f) -> (args...) -> f(args[0]) Which lets you do stuff like: recursive = do -> r = (n) -> if n > 0 then n*r(n-1) else 1 instead of: def recursive_gen(): def recursive(n): return n*recursive(n-1) if n > 0 else 1 return recursive recursive = recursive_gen() Of course, Coffeescript has its own quirks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 25 June 2013 00:13, Tim Chase wrote: > On 2013-06-24 23:39, Fábio Santos wrote: >> On 24 Jun 2013 23:35, "Tim Chase" wrote: >> > On 2013-06-25 07:38, Chris Angelico wrote: >> > > Python has no issues with breaking out of loops, and even has >> > > syntax specifically to complement it (the 'else:' clause). Use >> > > break/continue when appropriate. >> > >> > from minor_gripes import breaking_out_of_nested_loops_to_top_level >> >> for x, y in itertools.product(range(width), range(height)): > > This works nicely for certain use cases, but if there's additional > processing that needs to be done in the outer loops, it starts to get > hairy. As Ian Kelly mentions, I could really dig a labeled > break/continue in Python (it's one of the few ideas I like that Java > made pretty popular; though I can't say I particularly care for > Java's implementation). I'd love to see something like a decorator > where you could do things like the following pseudocode: > > @toplevel > for i in range(height): > for j in range(width): > for component in data[i,j]: > if condition: > continue toplevel > elif other_condition: > break toplevel > else: > other processing > > I'm not sure such a feature would ever arrive, but it would make it > easier than the current recommendation which is usually to either (1) > make inner loops into functions from which you can return; or (2) > raise a custom exception and then catch it in the outer loop. Guido says no; supposedly you can always just use a function. I don't agree, but I'm not Guido. Anyhoo, I prefer: for i in range(height) as toplevel: for j in range(width): break from toplevel Which reads like pure Python gold. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
jim...@aol.com: Syntax: fwhile X in ListY and conditionZ: There is precedent in Algol 68: for i from 0 to n while safe(i) do .. od which would also make a python proposal that needs no new key words: for i in range(n) while safe(i): .. The benefit of the syntax would be to concentrate the code expressing the domain of the loop rather than have it in separate locations. Not a big win in my opinion. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tue, Jun 25, 2013 at 2:20 PM, Benjamin Kaplan wrote: > On Mon, Jun 24, 2013 at 8:54 PM, Chris Angelico wrote: >> On Tue, Jun 25, 2013 at 12:01 PM, rusi wrote: >>> On Tuesday, June 25, 2013 3:08:57 AM UTC+5:30, Chris Angelico wrote: On Tue, Jun 25, 2013 at 5:52 AM, <> wrote: > (NOTE: Many people are being taught to avoid 'break' and 'continue' at > all > costs... Why? Why on earth should break/continue be avoided? >>> >>> Because breaks and continues are just goto-in-disguise? >>> >>> [Well so is while and if and function-call and... Who is to say that?] >> >> And that's still not a reason imho. You've just pointed out that >> they're all control-flow. :) >> >> ChrisA > > The reason I was given (which I promptly ignored, of course) is that > it's "best practice" to only have one exit point for a block of code. > Only one way of terminating your loop, only one "return" per function, > never use exceptions, etc. I think it originally came about as a way > to make sure that your clean-up code was called (and to make it easier > for code reviewers to make sure your clean up code was called) and > then started being passed around as a rule among programming teachers > who didn't have any experience outside the classroom. I've heard that "one exit point" rule before, too, but never any justification for it. Your explanation does at least make sense (albeit only in a language without even RAII), but I don't like silly rules like that :) I tend to write code on the principle of "fail and bail" (on finding a problem, 'return' or goto or break or whatever, rather than indenting all the subsequent code). It just seems cleaner that way than having the middle of your function run off the right hand edge of the screen for no reason :) Also, I consider error checks to be linear, not nested - if something could fail in three ways, that's three checks down in parallel, not one check with one check inside it with one check inside that. But maybe I just like C and assembly too much :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tuesday, June 25, 2013 4:44:44 AM UTC+5:30, alex23 wrote: > I'd probably just go with a generator expression to feed the for loop: > > for X in (i for i in ListY if conditionZ): > > Nice idiom -- thanks Yes it does not correspond to a takewhile (or break in the control structure world). It does correspond to a filter -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 6:41 PM, wu wei wrote: > It's still possible by raising a StopIteration within the condition > function: > > def is_part_of_header(x): > if header_condition: > return True > else: > raise StopIteration Which is basically just taking the break and moving it to somewhere else in the code, and meanwhile rendering the is_part_of_header function non-reusable. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 8:54 PM, Chris Angelico wrote: > On Tue, Jun 25, 2013 at 12:01 PM, rusi wrote: >> On Tuesday, June 25, 2013 3:08:57 AM UTC+5:30, Chris Angelico wrote: >>> On Tue, Jun 25, 2013 at 5:52 AM, <> wrote: >>> >>> > (NOTE: Many people are being taught to avoid 'break' and 'continue' at >>> > all >>> > costs... >>> >>> Why? Why on earth should break/continue be avoided? >> >> Because breaks and continues are just goto-in-disguise? >> >> [Well so is while and if and function-call and... Who is to say that?] > > And that's still not a reason imho. You've just pointed out that > they're all control-flow. :) > > ChrisA The reason I was given (which I promptly ignored, of course) is that it's "best practice" to only have one exit point for a block of code. Only one way of terminating your loop, only one "return" per function, never use exceptions, etc. I think it originally came about as a way to make sure that your clean-up code was called (and to make it easier for code reviewers to make sure your clean up code was called) and then started being passed around as a rule among programming teachers who didn't have any experience outside the classroom. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tue, Jun 25, 2013 at 12:01 PM, rusi wrote: > On Tuesday, June 25, 2013 3:08:57 AM UTC+5:30, Chris Angelico wrote: >> On Tue, Jun 25, 2013 at 5:52 AM, <> wrote: >> >> > (NOTE: Many people are being taught to avoid 'break' and 'continue' at all >> > costs... >> >> Why? Why on earth should break/continue be avoided? > > Because breaks and continues are just goto-in-disguise? > > [Well so is while and if and function-call and... Who is to say that?] And that's still not a reason imho. You've just pointed out that they're all control-flow. :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tuesday, June 25, 2013 3:08:57 AM UTC+5:30, Chris Angelico wrote: > On Tue, Jun 25, 2013 at 5:52 AM, <> wrote: > > > (NOTE: Many people are being taught to avoid 'break' and 'continue' at all > > costs... > > Why? Why on earth should break/continue be avoided? Because breaks and continues are just goto-in-disguise? [Well so is while and if and function-call and... Who is to say that?] -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tue, Jun 25, 2013 at 10:19 AM, Fábio Santos
wrote:
> for X in (i for i in open('largefile') if is_part_of_header(i)):
>
> The above code would be wasting time on IO and processing. It would load
> another line and calculate the condition for every line of the large file
> and I just wanted to loop over the few header lines.
>
> itertools.takewhile and fwhile/for..while actually stops the loop when the
> condition is not meant, while your example keeps checking the condition
> until the end of file, even though it is a generator expression.
>
Ah yes, of course, my bad.
It's still possible by raising a StopIteration within the condition
function:
def is_part_of_header(x):
if header_condition:
return True
else:
raise StopIteration
But yes, by this point any clarity of the generator expression approach
comes with the cost of more explicit setup of the breaking condition.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 25 Jun 2013 01:08, "alex23" wrote:
>
> On 25/06/2013 9:35 AM, Fábio Santos wrote:
>>
>> > I'd probably just go with a generator expression to feed the for loop:
>> >
>> > for X in (i for i in ListY if conditionZ):
>> >
>>
>> That is nice but it's not lazy. If the condition or the iterables took
>> too long to compute, it would be troublesome.
>
>
> I'm not sure I follow. It's a generator expression, not a list
comprehension, so the condition will be evaluated per item iterated over in
the generator, not across all valid items in ListY at once.
>
for X in (i for i in open('largefile') if is_part_of_header(i)):
The above code would be wasting time on IO and processing. It would load
another line and calculate the condition for every line of the large file
and I just wanted to loop over the few header lines.
itertools.takewhile and fwhile/for..while actually stops the loop when the
condition is not meant, while your example keeps checking the condition
until the end of file, even though it is a generator expression.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 25/06/2013 9:35 AM, Fábio Santos wrote: > I'd probably just go with a generator expression to feed the for loop: > > for X in (i for i in ListY if conditionZ): > That is nice but it's not lazy. If the condition or the iterables took too long to compute, it would be troublesome. I'm not sure I follow. It's a generator expression, not a list comprehension, so the condition will be evaluated per item iterated over in the generator, not across all valid items in ListY at once. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 25 Jun 2013 00:31, "alex23" wrote: > > On 25/06/2013 6:12 AM, Ian Kelly wrote: >> >> On Mon, Jun 24, 2013 at 1:52 PM, wrote: >>> >>> Syntax: >>> fwhile X in ListY and conditionZ: >>> >>> fwhile would act much like 'for', but would stop if the condition after the >>> 'and' is no longer True. >> >> >> I would advocate using the break myself. Another alternative is this: >> >> for X in itertools.takewhile(lambda X: conditionZ, ListY): >> ... > > > I'd probably just go with a generator expression to feed the for loop: > > for X in (i for i in ListY if conditionZ): > That is nice but it's not lazy. If the condition or the iterables took too long to compute, it would be troublesome. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 25/06/2013 6:12 AM, Ian Kelly wrote: On Mon, Jun 24, 2013 at 1:52 PM, wrote: Syntax: fwhile X in ListY and conditionZ: fwhile would act much like 'for', but would stop if the condition after the 'and' is no longer True. I would advocate using the break myself. Another alternative is this: for X in itertools.takewhile(lambda X: conditionZ, ListY): ... I'd probably just go with a generator expression to feed the for loop: for X in (i for i in ListY if conditionZ): -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 25 Jun 2013 00:06, "Fábio Santos" wrote: > I like how discussions on this list tend to go off topic ;) And now I'm off topic myself :( -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tue, Jun 25, 2013 at 8:43 AM, Ian Kelly wrote: > On Mon, Jun 24, 2013 at 4:41 PM, Fábio Santos > wrote: >> >> On 24 Jun 2013 22:29, "Ian Kelly" wrote: >>> >>> On Mon, Jun 24, 2013 at 2:34 PM, Fábio Santos >>> wrote: >>> > This can probably be best achieved by adding to the existing for loop, >>> > so maybe taking advantage of the existing for...if syntax and adding >>> > for...while would be a better idea? >>> >>> The for...if syntax only exists for comprehensions and generators. If >>> we're going to add for...while for loops, then we might as well go >>> ahead and add for...if loops there as well. >>> >>> That said, I do like this syntax better than "fwhile". >> >> Good point. Still, I don't see why for..if doesn't exist in for loops >> anyway. It may be lack of foresight, but I don't understand why at all. > > Because it adds more syntax to learn when learning the language, it > introduces more maintenance overhead, and it offers no clear benefit > over simply nesting an if inside a for. In more free-form languages, I implement this by simply omitting a line-break: for (int i=0;ihttp://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 2013-06-24 23:39, Fábio Santos wrote: > On 24 Jun 2013 23:35, "Tim Chase" wrote: > > On 2013-06-25 07:38, Chris Angelico wrote: > > > Python has no issues with breaking out of loops, and even has > > > syntax specifically to complement it (the 'else:' clause). Use > > > break/continue when appropriate. > > > > from minor_gripes import breaking_out_of_nested_loops_to_top_level > > for x, y in itertools.product(range(width), range(height)): This works nicely for certain use cases, but if there's additional processing that needs to be done in the outer loops, it starts to get hairy. As Ian Kelly mentions, I could really dig a labeled break/continue in Python (it's one of the few ideas I like that Java made pretty popular; though I can't say I particularly care for Java's implementation). I'd love to see something like a decorator where you could do things like the following pseudocode: @toplevel for i in range(height): for j in range(width): for component in data[i,j]: if condition: continue toplevel elif other_condition: break toplevel else: other processing I'm not sure such a feature would ever arrive, but it would make it easier than the current recommendation which is usually to either (1) make inner loops into functions from which you can return; or (2) raise a custom exception and then catch it in the outer loop. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 24/06/2013 23:30, Tim Chase wrote: On 2013-06-25 07:38, Chris Angelico wrote: Python has no issues with breaking out of loops, and even has syntax specifically to complement it (the 'else:' clause). Use break/continue when appropriate. from minor_gripes import breaking_out_of_nested_loops_to_top_level -tkc Doesn't the goto module http://entrian.com/goto/ fix this? :) -- "Steve is going for the pink ball - and for those of you who are watching in black and white, the pink is next to the green." Snooker commentator 'Whispering' Ted Lowe. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 25 Jun 2013 00:04, "MRAB" wrote: > > On 24/06/2013 23:35, Chris Angelico wrote: >> >> On Tue, Jun 25, 2013 at 8:30 AM, Tim Chase >> wrote: >>> >>> On 2013-06-25 07:38, Chris Angelico wrote: Python has no issues with breaking out of loops, and even has syntax specifically to complement it (the 'else:' clause). Use break/continue when appropriate. >>> >>> >>> from minor_gripes import breaking_out_of_nested_loops_to_top_level >> >> >> True. There are times I do wish for a 'goto'. But if goto were >> implemented, I would also use it for jumping _into_ loops, and I'm not >> sure that's going to make the feature popular :) >> > I think a better way would be to label the outer loop somehow and then > break out of it by name. I like how discussions on this list tend to go off topic ;) -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 24/06/2013 23:35, Chris Angelico wrote: On Tue, Jun 25, 2013 at 8:30 AM, Tim Chase wrote: On 2013-06-25 07:38, Chris Angelico wrote: Python has no issues with breaking out of loops, and even has syntax specifically to complement it (the 'else:' clause). Use break/continue when appropriate. from minor_gripes import breaking_out_of_nested_loops_to_top_level True. There are times I do wish for a 'goto'. But if goto were implemented, I would also use it for jumping _into_ loops, and I'm not sure that's going to make the feature popular :) I think a better way would be to label the outer loop somehow and then break out of it by name. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 4:35 PM, Chris Angelico wrote: > On Tue, Jun 25, 2013 at 8:30 AM, Tim Chase > wrote: >> On 2013-06-25 07:38, Chris Angelico wrote: >>> Python has no issues with breaking out of loops, and even has >>> syntax specifically to complement it (the 'else:' clause). Use >>> break/continue when appropriate. >> >> from minor_gripes import breaking_out_of_nested_loops_to_top_level > > True. There are times I do wish for a 'goto'. But if goto were > implemented, I would also use it for jumping _into_ loops, and I'm not > sure that's going to make the feature popular :) You can have labeled break and continue without going all the way to a goto statement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 24 Jun 2013 22:29, "Ian Kelly" wrote: > > On Mon, Jun 24, 2013 at 2:34 PM, Fábio Santos wrote: > > This can probably be best achieved by adding to the existing for loop, > > so maybe taking advantage of the existing for...if syntax and adding > > for...while would be a better idea? > > The for...if syntax only exists for comprehensions and generators. If > we're going to add for...while for loops, then we might as well go > ahead and add for...if loops there as well. > > That said, I do like this syntax better than "fwhile". Good point. Still, I don't see why for..if doesn't exist in for loops anyway. It may be lack of foresight, but I don't understand why at all. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 24 Jun 2013 23:35, "Tim Chase" wrote: > > On 2013-06-25 07:38, Chris Angelico wrote: > > Python has no issues with breaking out of loops, and even has > > syntax specifically to complement it (the 'else:' clause). Use > > break/continue when appropriate. > > from minor_gripes import breaking_out_of_nested_loops_to_top_level > > -tkc > for x, y in itertools.product(range(width), range(height)): -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 4:41 PM, Fábio Santos wrote: > > On 24 Jun 2013 22:29, "Ian Kelly" wrote: >> >> On Mon, Jun 24, 2013 at 2:34 PM, Fábio Santos >> wrote: >> > This can probably be best achieved by adding to the existing for loop, >> > so maybe taking advantage of the existing for...if syntax and adding >> > for...while would be a better idea? >> >> The for...if syntax only exists for comprehensions and generators. If >> we're going to add for...while for loops, then we might as well go >> ahead and add for...if loops there as well. >> >> That said, I do like this syntax better than "fwhile". > > Good point. Still, I don't see why for..if doesn't exist in for loops > anyway. It may be lack of foresight, but I don't understand why at all. Because it adds more syntax to learn when learning the language, it introduces more maintenance overhead, and it offers no clear benefit over simply nesting an if inside a for. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tue, Jun 25, 2013 at 8:30 AM, Tim Chase wrote: > On 2013-06-25 07:38, Chris Angelico wrote: >> Python has no issues with breaking out of loops, and even has >> syntax specifically to complement it (the 'else:' clause). Use >> break/continue when appropriate. > > from minor_gripes import breaking_out_of_nested_loops_to_top_level True. There are times I do wish for a 'goto'. But if goto were implemented, I would also use it for jumping _into_ loops, and I'm not sure that's going to make the feature popular :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 2013-06-25 07:38, Chris Angelico wrote: > Python has no issues with breaking out of loops, and even has > syntax specifically to complement it (the 'else:' clause). Use > break/continue when appropriate. from minor_gripes import breaking_out_of_nested_loops_to_top_level -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Tue, Jun 25, 2013 at 5:52 AM, wrote: > (NOTE: Many people are being taught to avoid 'break' and 'continue' at all > costs... Why? Why on earth should break/continue be avoided? I think that's the solution: teach people that loops are there to be interrupted and manipulated. And then it's a small step to jumping into the middle of a loop, and from there to Duff's Device... hmm, I'm not sure that strengthens my case, really. But anyway. Python has no issues with breaking out of loops, and even has syntax specifically to complement it (the 'else:' clause). Use break/continue when appropriate. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 2:34 PM, Fábio Santos wrote: > This can probably be best achieved by adding to the existing for loop, > so maybe taking advantage of the existing for...if syntax and adding > for...while would be a better idea? The for...if syntax only exists for comprehensions and generators. If we're going to add for...while for loops, then we might as well go ahead and add for...if loops there as well. That said, I do like this syntax better than "fwhile". -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 3:01 PM, Ian Kelly wrote: > On Mon, Jun 24, 2013 at 2:34 PM, Fábio Santos > wrote: >> This can probably be best achieved by adding to the existing for loop, >> so maybe taking advantage of the existing for...if syntax and adding >> for...while would be a better idea? > > The for...if syntax only exists for comprehensions and generators. If > we're going to add for...while for loops, then we might as well go > ahead and add for...if loops there as well. Which of course brings us to the for...if...while loop. Or should it be for...while...if? Or do we allow both, and if so, are the semantics the same or different? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
Your syntax makes great sense. Avoiding new keywords is obviously preferable. -Original Message- From: Fábio Santos To: jimjhb Cc: python-list Sent: Mon, Jun 24, 2013 4:34 pm Subject: Re: Is this PEP-able? fwhile On Mon, Jun 24, 2013 at 8:52 PM, wrote: > Syntax: > > fwhile X in ListY and conditionZ: > > The following would actually exactly as: for X in ListY: > > fwhile X in ListY and True: > > fwhile would act much like 'for', but would stop if the condition after the > 'and' is no longer True. > > The motivation is to be able to make use of all the great aspects of the > python 'for' (no indexing or explict > end condition check, etc.) and at the same time avoiding a 'break' from the > 'for'. > > (NOTE: Many people are being taught to avoid 'break' and 'continue' at all > costs, so they instead convert > the clean 'for' into a less-clean 'while'. Or they just let the 'for' run > out. You can argue against this teaching > (at least for Python) but that doesn't mean it's not prevalent and > prevailing.) > > [People who avoid the 'break' by functionalizing an inner portion of the > loop are just kidding themselves and making > their own code worse, IMO.] > > I'm not super familiar with CPython, but I'm pretty sure I could get this up > and working without too much effort. > The mandatory 'and' makes sense because 'or' would hold the end value valid > (weird) and not accomplish much. > The condition itself could of course have multiple parts to it, including > 'or's. > > It's possible the name 'fwhile' is not optimal, but that shouldn't affect > the overall merit/non-merit of the concept. > > Comments and Questions welcome. > > Thanks. > I can see where you are coming from, but this is probably not going to happen. The "and" keyword is also Also, the (amazing) python devs are concerned with overcomplicating the language syntax, which is bad for: newbies, other implementations of the language, and code readability. The syntax doesn't seem too obvious, and there is a new keyword, "fwhile". This can probably be best achieved by adding to the existing for loop, so maybe taking advantage of the existing for...if syntax and adding for...while would be a better idea? So, maybe: for x in y while cond: And for list/set/dict comprehensions and generator expressions: [x for x in range(123) while cond] Just maybe. -- Fábio Santos -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
I find itertools clumsy and wordy. You shouldn't have to have a lambda expression just to break out of a for! I agree to not cater to bad practices, but if a clean improvement is possible it will practically help code overall, even if theoretically people shouldn't be adopting a practice (don't use breaks) to the wrong circumstance (the python 'for' is not like other fors in other languages). -Jim -Original Message- From: Joshua Landau To: jimjhb Cc: python-list Sent: Mon, Jun 24, 2013 4:41 pm Subject: Re: Is this PEP-able? fwhile On 24 June 2013 20:52, wrote: > Syntax: > > fwhile X in ListY and conditionZ: > > The following would actually exactly as: for X in ListY: > > fwhile X in ListY and True: > > fwhile would act much like 'for', but would stop if the condition after the > 'and' is no longer True. > > The motivation is to be able to make use of all the great aspects of the > python 'for' (no indexing or explict > end condition check, etc.) and at the same time avoiding a 'break' from the > 'for'. There is one good reason not to use breaks: itertools. I often prefer a for-over-a-properly-constrained-iterable to a for-with-a-break, but there's no real reason to ever prefer a while. That said, why add this to the syntax when there's already functionality that gives you what you want? Just use itertools.takewhile as Ian Kelly says. > (NOTE: Many people are being taught to avoid 'break' and 'continue' at all > costs, so they instead convert > the clean 'for' into a less-clean 'while'. Or they just let the 'for' run > out. You can argue against this teaching > (at least for Python) but that doesn't mean it's not prevalent and > prevailing.) We shouldn't make a language around "people are taught the language badly - let us accommodate for their bad practices!" > [People who avoid the 'break' by functionalizing an inner portion of the > loop are just kidding themselves and making > their own code worse, IMO.] > > I'm not super familiar with CPython, but I'm pretty sure I could get this up > and working without too much effort. > The mandatory 'and' makes sense because 'or' would hold the end value valid > (weird) and not accomplish much. > The condition itself could of course have multiple parts to it, including > 'or's. > > It's possible the name 'fwhile' is not optimal, but that shouldn't affect > the overall merit/non-merit of the concept. "Possible"? It's more than just possible, *wink*. > Comments and Questions welcome. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On 24 June 2013 20:52, wrote: > Syntax: > > fwhile X in ListY and conditionZ: > > The following would actually exactly as: for X in ListY: > > fwhile X in ListY and True: > > fwhile would act much like 'for', but would stop if the condition after the > 'and' is no longer True. > > The motivation is to be able to make use of all the great aspects of the > python 'for' (no indexing or explict > end condition check, etc.) and at the same time avoiding a 'break' from the > 'for'. There is one good reason not to use breaks: itertools. I often prefer a for-over-a-properly-constrained-iterable to a for-with-a-break, but there's no real reason to ever prefer a while. That said, why add this to the syntax when there's already functionality that gives you what you want? Just use itertools.takewhile as Ian Kelly says. > (NOTE: Many people are being taught to avoid 'break' and 'continue' at all > costs, so they instead convert > the clean 'for' into a less-clean 'while'. Or they just let the 'for' run > out. You can argue against this teaching > (at least for Python) but that doesn't mean it's not prevalent and > prevailing.) We shouldn't make a language around "people are taught the language badly - let us accommodate for their bad practices!" > [People who avoid the 'break' by functionalizing an inner portion of the > loop are just kidding themselves and making > their own code worse, IMO.] > > I'm not super familiar with CPython, but I'm pretty sure I could get this up > and working without too much effort. > The mandatory 'and' makes sense because 'or' would hold the end value valid > (weird) and not accomplish much. > The condition itself could of course have multiple parts to it, including > 'or's. > > It's possible the name 'fwhile' is not optimal, but that shouldn't affect > the overall merit/non-merit of the concept. "Possible"? It's more than just possible, *wink*. > Comments and Questions welcome. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 8:52 PM, wrote: > Syntax: > > fwhile X in ListY and conditionZ: > > The following would actually exactly as: for X in ListY: > > fwhile X in ListY and True: > > fwhile would act much like 'for', but would stop if the condition after the > 'and' is no longer True. > > The motivation is to be able to make use of all the great aspects of the > python 'for' (no indexing or explict > end condition check, etc.) and at the same time avoiding a 'break' from the > 'for'. > > (NOTE: Many people are being taught to avoid 'break' and 'continue' at all > costs, so they instead convert > the clean 'for' into a less-clean 'while'. Or they just let the 'for' run > out. You can argue against this teaching > (at least for Python) but that doesn't mean it's not prevalent and > prevailing.) > > [People who avoid the 'break' by functionalizing an inner portion of the > loop are just kidding themselves and making > their own code worse, IMO.] > > I'm not super familiar with CPython, but I'm pretty sure I could get this up > and working without too much effort. > The mandatory 'and' makes sense because 'or' would hold the end value valid > (weird) and not accomplish much. > The condition itself could of course have multiple parts to it, including > 'or's. > > It's possible the name 'fwhile' is not optimal, but that shouldn't affect > the overall merit/non-merit of the concept. > > Comments and Questions welcome. > > Thanks. > I can see where you are coming from, but this is probably not going to happen. The "and" keyword is also Also, the (amazing) python devs are concerned with overcomplicating the language syntax, which is bad for: newbies, other implementations of the language, and code readability. The syntax doesn't seem too obvious, and there is a new keyword, "fwhile". This can probably be best achieved by adding to the existing for loop, so maybe taking advantage of the existing for...if syntax and adding for...while would be a better idea? So, maybe: for x in y while cond: And for list/set/dict comprehensions and generator expressions: [x for x in range(123) while cond] Just maybe. -- Fábio Santos -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 1:52 PM, wrote: > Syntax: > > fwhile X in ListY and conditionZ: Also, this syntax is ambiguous. Take for example the statement: fwhile X in ListA and ListB and ListC and ListD: At which "and" does the iterable expression stop and the condition expression begin? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? fwhile
On Mon, Jun 24, 2013 at 1:52 PM, wrote: > Syntax: > > fwhile X in ListY and conditionZ: > > The following would actually exactly as: for X in ListY: > > fwhile X in ListY and True: > > fwhile would act much like 'for', but would stop if the condition after the > 'and' is no longer True. > > The motivation is to be able to make use of all the great aspects of the > python 'for' (no indexing or explict > end condition check, etc.) and at the same time avoiding a 'break' from the > 'for'. I would advocate using the break myself. Another alternative is this: for X in itertools.takewhile(lambda X: conditionZ, ListY): ... -- http://mail.python.org/mailman/listinfo/python-list
Is this PEP-able? fwhile
Syntax: fwhile X in ListY and conditionZ: The following would actually exactly as: for X in ListY: fwhile X in ListY and True: fwhile would act much like 'for', but would stop if the condition after the 'and' is no longer True. The motivation is to be able to make use of all the great aspects of the python 'for' (no indexing or explict end condition check, etc.) and at the same time avoiding a 'break' from the 'for'. (NOTE: Many people are being taught to avoid 'break' and 'continue' at all costs, so they instead convert the clean 'for' into a less-clean 'while'. Or they just let the 'for' run out. You can argue against this teaching (at least for Python) but that doesn't mean it's not prevalent and prevailing.) [People who avoid the 'break' by functionalizing an inner portion of the loop are just kidding themselves and making their own code worse, IMO.] I'm not super familiar with CPython, but I'm pretty sure I could get this up and working without too much effort. The mandatory 'and' makes sense because 'or' would hold the end value valid (weird) and not accomplish much. The condition itself could of course have multiple parts to it, including 'or's. It's possible the name 'fwhile' is not optimal, but that shouldn't affect the overall merit/non-merit of the concept. Comments and Questions welcome. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
