Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #49092 > unrolled thread

Re: Is this PEP-able? fwhile

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Is this PEP-able? fwhile Chris Angelico <rosuav@gmail.com> - 2013-06-25 07:38 +1000
    Re: Is this PEP-able? fwhile rusi <rustompmody@gmail.com> - 2013-06-24 19:01 -0700
      Re: Is this PEP-able? fwhile Chris Angelico <rosuav@gmail.com> - 2013-06-25 13:54 +1000
      Re: Is this PEP-able? fwhile Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-06-24 21:20 -0700
      Re: Is this PEP-able? fwhile Chris Angelico <rosuav@gmail.com> - 2013-06-25 17:21 +1000
      Re: Is this PEP-able? fwhile Ian Kelly <ian.g.kelly@gmail.com> - 2013-06-25 10:00 -0600
        Re: Is this PEP-able? fwhile rusi <rustompmody@gmail.com> - 2013-06-25 09:19 -0700
          Re: Is this PEP-able? fwhile Neil Cerutti <neilc@norwich.edu> - 2013-06-26 13:09 +0000
      Re: Is this PEP-able? fwhile Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-25 20:40 -0400
        Re: Is this PEP-able? fwhile jfharden@gmail.com - 2013-06-26 03:00 -0700
        Re: Is this PEP-able? fwhile Jerry Peters <jerry@example.invalid> - 2013-06-26 19:56 +0000

#49092 — Re: Is this PEP-able? fwhile

On Tue, Jun 25, 2013 at 5:52 AM,  <jimjhb@aol.com> 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

[toc] | [next] | [standalone]

#49117

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?]

[toc] | [prev] | [next] | [standalone]

#49123

On Tue, Jun 25, 2013 at 12:01 PM, rusi <rustompmody@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#49125

On Mon, Jun 24, 2013 at 8:54 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Jun 25, 2013 at 12:01 PM, rusi <rustompmody@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#49133

On Tue, Jun 25, 2013 at 2:20 PM, Benjamin Kaplan
<benjamin.kaplan@case.edu> wrote:
> On Mon, Jun 24, 2013 at 8:54 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> On Tue, Jun 25, 2013 at 12:01 PM, rusi <rustompmody@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#49169

On Tue, Jun 25, 2013 at 1:21 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Jun 25, 2013 at 2:20 PM, Benjamin Kaplan
> <benjamin.kaplan@case.edu> 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.

[toc] | [prev] | [next] | [standalone]

#49172

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.

[toc] | [prev] | [next] | [standalone]

#49254

On 2013-06-25, rusi <rustompmody@gmail.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.

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

[toc] | [prev] | [next] | [standalone]

#49217

On Mon, 24 Jun 2013 19:01:11 -0700 (PDT), rusi <rustompmody@gmail.com>
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?)

	Granted -- allowing /multiple/ break/continue begins to look ugly.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#49239

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
   next    The "next" command is like the "continue" statement in C; it
           starts the next iteration of the loop:

                LINE: while (<STDIN>) {
                   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.

[toc] | [prev] | [next] | [standalone]

#49273

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Mon, 24 Jun 2013 19:01:11 -0700 (PDT), rusi <rustompmody@gmail.com>
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web