Re: "Goto" statement in Python

[Chris Angelico]

On Sun, Apr 16, 2017 at 5:21 PM, Mikhail V  wrote:
> I am in the category "I just want to express some
> algorithm and don't want to learn every year new concepts".
> I tend to think that extremely restricted syntax, in the sence
> of having only few flow control instructions actually helps with
> readability, despite I have never seriously used other languages
> than python so I cannot judge GOTO specifically.
> [...]
> Seriously, when I open some random .py file from the web
> and everywhere see class, class, class, kilometers of indentation...
> Hair around one-liners all over the files.
> And hedgehogs of try: except blocks, well, this is
> straining, and trying to learn why I need
> some of those, multiplies the pain.
> So your comment applies to me too and I must sound
> like an old stupid man I suppose?

You sound more like someone who's never grown beyond a one-man
project. Most of us understand code primarily as a tool for
communicating between humans, and secondarily for the computer to
execute. And you most definitely sound like someone who thinks in the
concrete, not in the abstract. These constructs are to express human
concepts, even though they take a lot of low-level tools to make them
up.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 14 April 2017 at 03:44, Steve D'Aprano  wrote:
> On Fri, 14 Apr 2017 12:52 am, bartc wrote:
>
>> I know this isn't the Python need-for-speed thread, but this is a
>> classic example where the lack of one simple feature leads to using
>> slower, more cumbersome ones.
>
> Dear gods, have I fallen back in time to 1975 again?
>

Everything new is definitely better, right?

> Are there reasonable uses for GOTO? Perhaps. There are semi-structured
> restricted versions of GOTO, like exceptions, break and return, but an
> unrestricted GOTO where you can jump anywhere in the program is a terrible
> feature

Yes I suppose, but I know too little about who restricts or
allows and how. And in python it is allowed to mistype
for example "while True :" in any part of the
.py file, as well as one can accidentally mess up with
indentation.
But indeed, Python has very restricted syntax and it is very good.


> Even that's not enough for some. Donald Knuth, who supports the use of GOTO
> under some circumstances, maintains that any program using GOTOs should
> have the invariant that its flow chart can be drawn with all forward
> branches on the left, all backward branches on the right, and no branches
> crossing each other.

I am in the category "I just want to express some
algorithm and don't want to learn every year new concepts".
I tend to think that extremely restricted syntax, in the sence
of having only few flow control instructions actually helps with
readability, despite I have never seriously used other languages
than python so I cannot judge GOTO specifically.

But that comes to many other aspects, most of the time
I just want my code look consistent and readable
and this is more representational problem.
And I suppose that with Python, what bothers
me is  zig-zags of indentation.

Now regardless of Python :
if I would have, say 2 forms of GOTO,
ie direct GOTO and e.g. 'loop' ,

an improvised pseudocode example:

"""
in_menu = true

SUB -
 init some
 draw thing

 # if skip_scan : goto .x

loop
|K=readkey()
|if  K[shift] :
|goto .1
|if  K[m] :
|in_menu = false
|goto .1
|if  K[o] :
|in_menu = false
|.1  make something
|make something
|if (in_menu = false) : goto .x
\__

.x
 clean_up something
 clean_up something

"""

or a classic:

x, y = 0
xx, yy = 300

loop
|loop
||
||   x = x + 1
||   if (x+y) > 100 : goto .x
||   if (x>xx) : goto .1
|\__
|
|.1
|y = y + 1
|if (x>xx) : goto .x
\__

.x

"""

So with 'else'-less condition statement, goto, and loop
construct I would have simpler representation simply because
I would have no 'else', for(), etc... And I'd avoid nested loops as much
as i can.
So less indentation zig-zags and plain "column" code look everywhere,
I think that is what many programmers are looking for.
Just from the reader's POV: having implicit labels for exiting loop
is IMO not worse than additional keywords e.g. "break"...
At least I would not be so fast to judge that.
It is just the question, *how would I input and edit such code*
to avoids typos and renaming labels.


[...]
>> (** Although I find code full of class definitions, one-liners, decorators
>> and all the other esoterics, incomprehensive. I'm sure I'm not the only
>> one, so perhaps readability isn't too much of a priority either.)

>Classes and decorators are not esoteric. You sound like an old man who
>complains about this new-fangled "telephone", and how things were so much
>better when we had messenger boys to deliver messages anywhere in the city.

Seriously, when I open some random .py file from the web
and everywhere see class, class, class, kilometers of indentation...
Hair around one-liners all over the files.
And hedgehogs of try: except blocks, well, this is
straining, and trying to learn why I need
some of those, multiplies the pain.
So your comment applies to me too and I must sound
like an old stupid man I suppose?
And I don't like new "telephones" - they are heavy, need charge
every 2 day, does not fit in the hand well, and just to repat
the last call I need to swipe the stupid touch screen.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rob Gaddi]

On 04/14/2017 07:19 AM, Dennis Lee Bieber wrote:

On Fri, 14 Apr 2017 11:44:59 +1000, Steve D'Aprano
 declaimed the following:



Even that's not enough for some. Donald Knuth, who supports the use of GOTO
under some circumstances, maintains that any program using GOTOs should
have the invariant that its flow chart can be drawn with all forward
branches on the left, all backward branches on the right, and no branches
crossing each other.



Good thing I never had him for an instructor... My practice, when last
flow-charting, favored back-branches on the left.

After all, I read left-to-right/top-to-bottom, so forward branches
going right and down seem natural. Encountering a branch going left sort of
implies "re-reading" part of the chart; going upwards...



Yeah, but I love the naked concept there.  It pretty much encapsulates 
what I find to be the only useful use of GOTO in any reasonable language 
in a simple, easy to visualize way.  If your GOTOs are crossing you've 
done something wrong.


If more people had good mechanisms for visualizing their code I'd use 
far less profanity literally every day of my life.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Chris Angelico]

On Sat, Apr 15, 2017 at 12:13 AM, Dennis Lee Bieber
 wrote:
> On Thu, 13 Apr 2017 18:36:57 -0600, Ian Kelly 
> declaimed the following:
>
>>
>>Well, you can do it in Assembly. And BASIC, if you count the primitive
>>GOSUB-type subroutines, though modern BASICs have real subroutines
>>that don't allow it.
>>
> REXX probably allows it too... (No GOTO, but the SIGNAL statement can
> do unconditional jumps to named labels)... Hmmm, if I read the manual
> correctly, any use of SIGNAL will terminate loops, even if the SIGNAL and
> target are both within the same loop.

This is correct. Annoyingly, it also wipes out indentation in the
TRACE output, so you really want to use it *only* for error handling
(which is its stated purpose).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Chris Green]

Bernd Nawothnig  wrote:
> On 2017-04-13, Mikhail V wrote:
> > On 13 April 2017 at 18:48, Ian Kelly  wrote:
> >> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
> >>> Now I wonder, have we already collected *all* bells and whistles of Python
> >>> in these two examples, or is there something else for expressing trivial 
> >>> thing.
> >>
> >> Functions and exceptions are considered "bells and whistles"?
> >
> > You mean probably classes and exceptions? For me, indeed they are,
> > but it depends.
> >
> > And breaking the code into def() chunks that are not
> > functions but just chunks... I don't know, looks bad.
> 
> Organising code in a bunch of small functions is by far better coding
> style and better readable than put it all together in one chunk. And
> that holds for all programming languages, not only for Python.
> 
The functions need *some* reason for being an entity though.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Bernd Nawothnig]

On 2017-04-13, Grant Edwards wrote:
> On 2017-04-13, Rob Gaddi  wrote:
>
>> No, C doesn't support exception handling.  As a result, handling error 
>> conditions in C is a huge pain for which (forward-only) goto is often, 
>> while not the only remedy, the least painful one.
>
> Indeed. That is almost the only place I use 'goto' in C, and the
> almost the only place I see others use it.  Very occasionally, you see
> a the error handling goto refactored into a backwards "goto retry":
>
> this code
>
> foo()
>   {
>   while (1)
> {
>   
>   if ()
>goto error:
>   
>   return;
>
> error:
>   
> }
>   }

foo()
  {
  int done = 0;
  while (! done)
{
  
  if () {

  } else {
done = 1;

 }
  }




Bernd

-- 
Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’
haben – und Geld. Die Antisemiten – ein Name der
‘Schlechtweggekommenenen’ [Friedrich Nietzsche]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Bernd Nawothnig]

On 2017-04-13, Mikhail V wrote:
> On 13 April 2017 at 18:48, Ian Kelly  wrote:
>> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
>>> Now I wonder, have we already collected *all* bells and whistles of Python
>>> in these two examples, or is there something else for expressing trivial 
>>> thing.
>>
>> Functions and exceptions are considered "bells and whistles"?
>
> You mean probably classes and exceptions? For me, indeed they are,
> but it depends.
>
> And breaking the code into def() chunks that are not
> functions but just chunks... I don't know, looks bad.

Organising code in a bunch of small functions is by far better coding
style and better readable than put it all together in one chunk. And
that holds for all programming languages, not only for Python.



Bernd

-- 
Die Antisemiten vergeben es den Juden nicht, dass die Juden ‘Geist’
haben – und Geld. Die Antisemiten – ein Name der
‘Schlechtweggekommenenen’ [Friedrich Nietzsche]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[bartc]

On 14/04/2017 02:44, Steve D'Aprano wrote:

On Fri, 14 Apr 2017 12:52 am, bartc wrote:


I know this isn't the Python need-for-speed thread, but this is a
classic example where the lack of one simple feature leads to using
slower, more cumbersome ones.


Dear gods, have I fallen back in time to 1975 again?

The Goto Wars are over, and the structured programming camp won the war
decisively.

Are functions/procedures *technically* slower than GOTOs? Yes. So what?
You're nano-optimizing the wrong thing: you're saving a microsecond of
runtime at the cost of a megasecond of development and maintenance time.


Usually, yes. (And when you run CPython, whatever speed you do get, is 
partly thanks to compiler writers choosing jumps, or in-lining, over 
function calls. All those nanoseconds add up.)


However my comment wasn't specifically about goto. It's about using a 
slower feature to get around the lack of another feature that could have 
been implemented efficiently.



Function calls, returns and generators are rather more heavyweight in
comparison.


And enormously better.


It depends if your application is speed-sensitive. Much scripting code 
isn't, or if it is, most of the work is done outside the language.


But sometimes you want your dynamic code to do some actual work of its 
own that involves executing byte-code, rather than calling some compiled 
code. And performance can matter.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rustom Mody]

On Friday, April 14, 2017 at 7:15:11 AM UTC+5:30, Steve D'Aprano wrote:
> On Fri, 14 Apr 2017 12:52 am, bartc wrote:
> 
> > I know this isn't the Python need-for-speed thread, but this is a
> > classic example where the lack of one simple feature leads to using
> > slower, more cumbersome ones.
> 
> Dear gods, have I fallen back in time to 1975 again?

Good that you start with the suggestion that we are not in 1975



> Features should not be judged solely on their usefulness to the best 1% of
> programmers using the feature in the best possible way. You also need to
> consider the lesser mortals, the below-average 50% of programmers who will
> use the feature in sub-optimal if not outright terrible ways.
> 
> GOTOs are far to easy to abuse. The harm that they do is outweighed a
> thousand times by the rare positive use. Most languages do well to avoid
> GOTO, even if that means that there are one or two rare uses that have to
> be written slightly sub-optimally for the lack.

That sounds very 1970s to me.

With the languages that I (and presumably you) grew up with using gotos was
too easy; not using was hard or impossible.
The most structured was Pascal which set out to be ornery by making one declare
labels. With everything else — Fortran-IV, Basic, assembler — it was next to 
impossible.

Cut to 2017 and take a random 20 year old brought up on 
python/java/ruby/javascript/haskell

Where/how would he have learnt to use gotos?

In short: In 1968 "Goto statement considered harmful" was a necessary viewpoint.
Today its a quasi-religious bias without basis.

Personal Note: Much of the direction that my programming/teaching has taken in
the last 30 years can be traced to a statement made by a teacher when I was 
graduating:

“What the goto does to control-structure, the assignment does to data-structure”
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Steve D'Aprano]

On Fri, 14 Apr 2017 12:52 am, bartc wrote:

> I know this isn't the Python need-for-speed thread, but this is a
> classic example where the lack of one simple feature leads to using
> slower, more cumbersome ones.

Dear gods, have I fallen back in time to 1975 again?

The Goto Wars are over, and the structured programming camp won the war
decisively.

Are functions/procedures *technically* slower than GOTOs? Yes. So what?
You're nano-optimizing the wrong thing: you're saving a microsecond of
runtime at the cost of a megasecond of development and maintenance time.

At the point that you say "Function calls ... are rather more heavyweight"
the whole argument becomes farcical. Function calls are so prevalent in
modern structured programming (whether you write in procedural, functional
or object-oriented style, or a combination of all three) that saving one or
two function calls isn't even a micro-optimization, especially not in a
high-level language.

To save any meaningful time, you would need to return to the bad-old-days of
unmaintainable unstructured spaghetti code.

This debate about the usefulness of GOTO in modern languages reminds me of
the sort of people who will drive around the city for an hour looking to
save 0.1 cent on the cost of petrol (gasoline for Americans).


> 'goto' would be one easy-to-execute byte-code; no variables, objects or
> types to worry about. If implemented properly (with the byte-code
> compiler using a dedicated name-space for labels) there would be no name
> lookups.

I don't care much about the implementation of GOTO. I care a lot about the
code written that includes GOTOs.

Are there reasonable uses for GOTO? Perhaps. There are semi-structured
restricted versions of GOTO, like exceptions, break and return, but an
unrestricted GOTO where you can jump anywhere in the program is a terrible
feature for anything but the smallest, most trivial programs. To be even
*close* to safe, you have to restrict GOTO considerably. At the very
minimum, you need two restrictions:

- cannot jump into the middle of a procedure or function;

- cannot jump immediately out of a procedure or function without 
  cleaning up the stack and other handling.


Even that's not enough for some. Donald Knuth, who supports the use of GOTO
under some circumstances, maintains that any program using GOTOs should
have the invariant that its flow chart can be drawn with all forward
branches on the left, all backward branches on the right, and no branches
crossing each other.

Features should not be judged solely on their usefulness to the best 1% of
programmers using the feature in the best possible way. You also need to
consider the lesser mortals, the below-average 50% of programmers who will
use the feature in sub-optimal if not outright terrible ways.

GOTOs are far to easy to abuse. The harm that they do is outweighed a
thousand times by the rare positive use. Most languages do well to avoid
GOTO, even if that means that there are one or two rare uses that have to
be written slightly sub-optimally for the lack.


> Function calls, returns and generators are rather more heavyweight in
> comparison.

And enormously better.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 4:59 PM, bartc  wrote:
> On 13/04/2017 22:58, Ian Kelly wrote:
>>
>> On Thu, Apr 13, 2017 at 3:27 PM, Dennis Lee Bieber
>>  wrote:
>>>
>>> On Thu, 13 Apr 2017 15:52:24 +0100, bartc  declaimed the
>>> following:
>>>
 'goto' would be one easy-to-execute byte-code; no variables, objects or
 types to worry about. If implemented properly (with the byte-code
 compiler using a dedicated name-space for labels) there would be no name
 lookups.

>>>
>>> Only if GOTO is not allowed to break out of namespaces...
>>>
>>> NO GOTO from inside a function to some global catch-all
>>> handler...
>
>
> (That doesn't happen. No sane language would allow it, not on the user-side
> anyway.)

Well, you can do it in Assembly. And BASIC, if you count the primitive
GOSUB-type subroutines, though modern BASICs have real subroutines
that don't allow it.

>>> Once you permit uncontrolled/unlimited GOTO you have to be
>>> concerned
>>> with stack-frames and object life-times.
>>
>>
>> Even within a function you would still have to be concerned about a
>> goto from inside a try or with block to outside of that block, as the
>> finally block or the context manager's __exit__ still need to be
>> executed on the way out.
>
>
> So how does 'break' manage it? I assume break works from inside a try- or
> with-block.

Yes, it would have to work similarly to break, continue and return. I
didn't mean to imply that it was impossible, only that it's not quite
as simple as just modifying a program counter.

For reference, here's what break inside a try block compiles to:

>>> dis.dis("""
... while True:
... try:
... break
... finally:
... print("Bye")
... """)
  2   0 SETUP_LOOP  22 (to 24)

  3 >>2 SETUP_FINALLY6 (to 10)

  4   4 BREAK_LOOP
  6 POP_BLOCK
  8 LOAD_CONST   0 (None)

  6 >>   10 LOAD_NAME0 (print)
 12 LOAD_CONST   1 ('Bye')
 14 CALL_FUNCTION1
 16 POP_TOP
 18 END_FINALLY
 20 JUMP_ABSOLUTE2
 22 POP_BLOCK
>>   24 LOAD_CONST   0 (None)
 26 RETURN_VALUE
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[bartc]

On 13/04/2017 22:58, Ian Kelly wrote:

On Thu, Apr 13, 2017 at 3:27 PM, Dennis Lee Bieber
 wrote:

On Thu, 13 Apr 2017 15:52:24 +0100, bartc  declaimed the
following:


'goto' would be one easy-to-execute byte-code; no variables, objects or
types to worry about. If implemented properly (with the byte-code
compiler using a dedicated name-space for labels) there would be no name
lookups.



Only if GOTO is not allowed to break out of namespaces...

NO GOTO from inside a function to some global catch-all handler...


(That doesn't happen. No sane language would allow it, not on the 
user-side anyway.)



Once you permit uncontrolled/unlimited GOTO you have to be concerned
with stack-frames and object life-times.


Even within a function you would still have to be concerned about a
goto from inside a try or with block to outside of that block, as the
finally block or the context manager's __exit__ still need to be
executed on the way out.


So how does 'break' manage it? I assume break works from inside a try- 
or with-block.


Jumping /into/ such a block might be more tricky, but it is simple 
enough to not allow it.


--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 3:27 PM, Dennis Lee Bieber
 wrote:
> On Thu, 13 Apr 2017 15:52:24 +0100, bartc  declaimed the
> following:
>
>>'goto' would be one easy-to-execute byte-code; no variables, objects or
>>types to worry about. If implemented properly (with the byte-code
>>compiler using a dedicated name-space for labels) there would be no name
>>lookups.
>>
>
> Only if GOTO is not allowed to break out of namespaces...
>
> NO GOTO from inside a function to some global catch-all handler... No
> GOTO from a global scope into a non-global scope.
>
> Once you permit uncontrolled/unlimited GOTO you have to be concerned
> with stack-frames and object life-times.

Even within a function you would still have to be concerned about a
goto from inside a try or with block to outside of that block, as the
finally block or the context manager's __exit__ still need to be
executed on the way out.

Not to mention the time-honored tradition of using goto to jump INTO a
block, such as Duff's Device.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Marko Rauhamaa]

Rob Gaddi :

> On 04/13/2017 08:26 AM, Marko Rauhamaa wrote:
>> I have occasionally felt the urge to try "goto" in my C code, but having
>> written it, I have taken it out. It just doesn't make the code look more
>> elegant or robust. Unlike "break" or "return," "goto" makes me uneasy
>> about variable scope and lifetime.
> [...]
> You see it all the time in kernel code or when doing I/O.  A pretty
> common pattern is:
>
>   int return_val = 1;
>   if (init_thing(x)) goto bk1;
>   if (init_thing(y)) goto bk2;
>   if (init_thing(z)) goto bk3;
>
>   do_things_with(x, y, z);
>   return_val = 0;
>
>   bk3:  cleanup_thing(z);
>   bk2:  cleanup_thing(y);
>   bk1:  cleanup_thing(x);
>   return return_val;

I know, but I still don't like it.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Grant Edwards]

On 2017-04-13, Rob Gaddi  wrote:

> No, C doesn't support exception handling.  As a result, handling error 
> conditions in C is a huge pain for which (forward-only) goto is often, 
> while not the only remedy, the least painful one.

Indeed. That is almost the only place I use 'goto' in C, and the
almost the only place I see others use it.  Very occasionally, you see
a the error handling goto refactored into a backwards "goto retry":

this code

foo()
  {
  while (1)
{
  
  if ()
   goto error:
  
  return;

error:
  
}
  }

becomes

  foo()
  {
retry:
  
  if ()
{
   
   goto retry:
}
  
  }

I happen to find the latter easier to read.

Fortunately, Python doesn't need goto to deal with things like that.

> Or if you've really developed a need for self-harm, setjmp/longjmp.

I've tried to use setjmp/longjmp for error handling a few times.  It
never went well...

-- 
Grant Edwards   grant.b.edwardsYow! Catsup and Mustard all
  at   over the place!  It's the
  gmail.comHuman Hamburger!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 13 April 2017 at 19:38, Ian Kelly  wrote:
> On Thu, Apr 13, 2017 at 11:25 AM, Mikhail V  wrote:
>> On 13 April 2017 at 18:48, Ian Kelly  wrote:
>>> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
 Now I wonder, have we already collected *all* bells and whistles of Python
 in these two examples, or is there something else for expressing trivial 
 thing.
>>>
>>> Functions and exceptions are considered "bells and whistles"?
>>
>> You mean probably classes and exceptions? For me, indeed they are,
>> but it depends.
>
> No, I meant functions (the first example) and exceptions (the second example).
>
>> And breaking the code into def() chunks that are not
>> functions but just chunks... I don't know, looks bad.
>
> I don't know what you mean by this. There is no such thing as a "def()
> chunk" that is not a function.

I mean that in my example I have consequent code and Rob takes a part of the
code and puts it in a function. And this is just a part of code, I don't need
here anything to wrap or return and don't want to scroll up and down and
collect it all in my brain back into original sequence. Therefore I've called
it abstract art.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rustom Mody]

On Thursday, April 13, 2017 at 11:19:38 PM UTC+5:30, Ian wrote:
> On Thu, Apr 13, 2017 at 11:39 AM, Rustom Mody wrote:
> > My broader point (vive la Trump) was that if we learn to actively tolerate
> > people with views wildly far from ours, the world would be a better place.
> 
> I fail to see how my comment "Functions and exceptions are considered
> 'bells and whistles'?" suggests intolerance on my part.

It was not directed specifically at you but at the overall quality of responses
that Mikhail is receiving for his (to me admittedly) outlandish views
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 11:39 AM, Rustom Mody  wrote:
> My broader point (vive la Trump) was that if we learn to actively tolerate
> people with views wildly far from ours, the world would be a better place.

I fail to see how my comment "Functions and exceptions are considered
'bells and whistles'?" suggests intolerance on my part.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rob Gaddi]

On 04/13/2017 08:26 AM, Marko Rauhamaa wrote:

Chris Angelico :


Personally, I can't remember the last time I yearned for "goto" in
Python, and the only times I've ever wished for it or used it in other
languages have been multi-loop breaks or "for...else" blocks. And
neither is very frequent.


I have occasionally felt the urge to try "goto" in my C code, but having
written it, I have taken it out. It just doesn't make the code look more
elegant or robust. Unlike "break" or "return," "goto" makes me uneasy
about variable scope and lifetime.

Maybe it would work in some state machine implementation. Some 30 years
ago I wrote a compiler. The parser came out nicer with methodical use of
"goto," but even then, I used a parsing-specific macro to wrap it.


Marko



You see it all the time in kernel code or when doing I/O.  A pretty 
common pattern is:


  int return_val = 1;
  if (init_thing(x)) goto bk1;
  if (init_thing(y)) goto bk2;
  if (init_thing(z)) goto bk3;

  do_things_with(x, y, z);
  return_val = 0;

  bk3:  cleanup_thing(z);
  bk2:  cleanup_thing(y);
  bk1:  cleanup_thing(x);
  return return_val;

But the point is, in Python we have context managers and exceptions and 
classes, all of which serve to allow you to not have to explicitly lay 
out how to wind yourself step-by-step back out of the situation you've 
gotten yourself into.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rustom Mody]

On Thursday, April 13, 2017 at 10:56:53 PM UTC+5:30, Rob Gaddi wrote:
> On 04/13/2017 10:13 AM, Rustom Mody wrote:
> > On Thursday, April 13, 2017 at 10:19:33 PM UTC+5:30, Ian wrote:
> >> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
> >>> Now I wonder, have we already collected *all* bells and whistles of Python
> >>> in these two examples, or is there something else for expressing trivial 
> >>> thing.
> >>
> >> Functions and exceptions are considered "bells and whistles"?
> >
> > People's tastes differ… violently on
> > - food
> > - music
> > - opposite sex
> >
> > What to do??
> > Ask Trump?
> > [I guess we now need a Godwin 2.0 with :s/Hitler/Trump ]
> >
> > I wonder if you noticed that you classed functions together with 
> > exceptions...
> > presumably as basic elements.
> > And that the bedrock of much contemporary computer technology — 
> > linux-kernel,
> > even (C)Python itself, viz C — does not support one of these
> >
> 
> No, C doesn't support exception handling.  As a result, handling error 
> conditions in C is a huge pain for which (forward-only) goto is often, 
> while not the only remedy, the least painful one.  Or if you've really 
> developed a need for self-harm, setjmp/longjmp.  Or, as is more 
> frequently the case in code in the wild, error conditions simply don't 
> get checked for and come as a surprise and/or segfault later on.
> 
> Python is a radically higher level language than C.  Python supports 
> different structures than C, largely and specifically so that you don't 
> have to do things in some of the error-prone ways you would do them in 
> C.  Therefore, a given task should be solved differently in Python than 
> in C.

You are answering to a different issue than I was: Sure C and python are done
differently [your point]
I was saying that if Mikhail finds exceptions (and as he later explained 
classes) as a heavy-duty solution to a control-flow issue, he has a point

> 
> I try very hard to write Python when I write Python, and to write C when 
> I write C.  And to write through the tears when I write C++.

C++ has exceptions but no gc
Haskell has gc (like python) but no exceptions
So that suggests that while desirable, both are not in the bare-minimum set

My broader point (vive la Trump) was that if we learn to actively tolerate 
people with views wildly far from ours, the world would be a better place.

So what would I say to (people like) Mikhail?
"Here's the sources mate! Fork it! And cheers!"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 11:25 AM, Mikhail V  wrote:
> On 13 April 2017 at 18:48, Ian Kelly  wrote:
>> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
>>> Now I wonder, have we already collected *all* bells and whistles of Python
>>> in these two examples, or is there something else for expressing trivial 
>>> thing.
>>
>> Functions and exceptions are considered "bells and whistles"?
>
> You mean probably classes and exceptions? For me, indeed they are,
> but it depends.

No, I meant functions (the first example) and exceptions (the second example).

> And breaking the code into def() chunks that are not
> functions but just chunks... I don't know, looks bad.

I don't know what you mean by this. There is no such thing as a "def()
chunk" that is not a function.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 11:13 AM, Rustom Mody  wrote:
> What to do??
> Ask Trump?
> [I guess we now need a Godwin 2.0 with :s/Hitler/Trump ]

Not even close. Whatever one's opinion may be of Trump, he hasn't
murdered millions of people.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rob Gaddi]

On 04/13/2017 10:13 AM, Rustom Mody wrote:

On Thursday, April 13, 2017 at 10:19:33 PM UTC+5:30, Ian wrote:

On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:

Now I wonder, have we already collected *all* bells and whistles of Python
in these two examples, or is there something else for expressing trivial thing.


Functions and exceptions are considered "bells and whistles"?


People's tastes differ… violently on
- food
- music
- opposite sex

What to do??
Ask Trump?
[I guess we now need a Godwin 2.0 with :s/Hitler/Trump ]

I wonder if you noticed that you classed functions together with exceptions...
presumably as basic elements.
And that the bedrock of much contemporary computer technology — linux-kernel,
even (C)Python itself, viz C — does not support one of these



No, C doesn't support exception handling.  As a result, handling error 
conditions in C is a huge pain for which (forward-only) goto is often, 
while not the only remedy, the least painful one.  Or if you've really 
developed a need for self-harm, setjmp/longjmp.  Or, as is more 
frequently the case in code in the wild, error conditions simply don't 
get checked for and come as a surprise and/or segfault later on.


Python is a radically higher level language than C.  Python supports 
different structures than C, largely and specifically so that you don't 
have to do things in some of the error-prone ways you would do them in 
C.  Therefore, a given task should be solved differently in Python than 
in C.


I try very hard to write Python when I write Python, and to write C when 
I write C.  And to write through the tears when I write C++.


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Thomas Nyberg]

On 04/12/2017 04:42 PM, Mikhail V wrote:
> For me it looks clear and I'd say easy to comprehend,
> Main critic would be obviously that it is not
> a good, *scalable application*, but quite often I don't
> even have this in mind, and just want to express a
> step-by-step direct instructions.

I think that scalability is the only objectively reasonable (at least as
far as this kind of argument could be objective) argument against gotos.
They're not fundamentally a bad idea (the people who put them into
certain languages weren't stupid after all), but they do seem to create
a maintenance and complexity burden as the codebase grows. But if you're
talking one off single scripts as your example, I think you can safely
use many habits considered bad by most. That's simply not the scenario
where gotos create a problem.

There are of course many different ways you can get around using them,
but there are certainly cases where that's exactly what you want and a
substitute will always be a substitute and it may feel lacking. It's
just a matter of taste really.

Cheers,
Thomas
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 13 April 2017 at 18:48, Ian Kelly  wrote:
> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
>> Now I wonder, have we already collected *all* bells and whistles of Python
>> in these two examples, or is there something else for expressing trivial 
>> thing.
>
> Functions and exceptions are considered "bells and whistles"?

You mean probably classes and exceptions? For me, indeed they are,
but it depends.

And breaking the code into def() chunks that are not
functions but just chunks... I don't know, looks bad.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[bartc]

On 13/04/2017 16:03, Ian Kelly wrote:

On Thu, Apr 13, 2017 at 8:52 AM, bartc  wrote:

On 13/04/2017 15:35, Chris Angelico wrote:

Personally, I can't remember the last time I yearned for "goto" in
Python, and the only times I've ever wished for it or used it in other
languages have been multi-loop breaks or "for...else" blocks. And
neither is very frequent.



It might be a better idea to have a multi-level loop break then. This would
also be an absolute jump byte-code.


This has previously been proposed and rejected:
https://www.python.org/dev/peps/pep-3136/


Poorly presented I think with, what, five possible ways of adding it?


Rejection notice:
https://mail.python.org/pipermail/python-3000/2007-July/008663.html


Rejected because it would only occur in complex code? That's just where 
it would help!


I think it should be in for completeness, and to avoid this bug in the 
language; start with:


 for i in range(n):
break;

break inside a loop; that's currently allowed. Now for reasons of logic, 
that break is put inside an 'if' branch:


 for i in range(n):
if cond:
   break;

The break still works. But if, for any reason at all, that break ended 
up inside a nested loop instead of a nested if:


 for i in range(n):
while cond:
   break;

Now it no longer works as expected. The break has been 'captured' by the 
new loop.


(IME most breaks from loops are either from the innermost loop, or from 
the outermost one. For these two cases, you don't need naming, labelling 
or numbering of loops. Just 'break [inner]' or 'break outer'.)


--
bartc

--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Rustom Mody]

On Thursday, April 13, 2017 at 10:19:33 PM UTC+5:30, Ian wrote:
> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
> > Now I wonder, have we already collected *all* bells and whistles of Python
> > in these two examples, or is there something else for expressing trivial 
> > thing.
> 
> Functions and exceptions are considered "bells and whistles"?

People's tastes differ… violently on
- food
- music
- opposite sex

What to do??
Ask Trump?
[I guess we now need a Godwin 2.0 with :s/Hitler/Trump ]

I wonder if you noticed that you classed functions together with exceptions...
presumably as basic elements.
And that the bedrock of much contemporary computer technology — linux-kernel,
even (C)Python itself, viz C — does not support one of these
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V  wrote:
> Now I wonder, have we already collected *all* bells and whistles of Python
> in these two examples, or is there something else for expressing trivial 
> thing.

Functions and exceptions are considered "bells and whistles"?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 13 April 2017 at 02:17, Rob Gaddi  wrote:

>
> def finder:
>   for s in S:
> if s == 'i':
>   return 'found on stage 1'
>
>   S = S + ' hello world'
>   for s in S:
> if s == 'd':
>   return 'found on stage 2'
>
>   raise ValueError('not found; S=' + S)
>
> try:
>   message = finder()
>   print(message)
>   log += message
> except ValueError as e:
>   print(e)
>

Mother of God... This is like placing some abstract art into a gallery
of monumentalism art.
I am upset and need some healing therapy now.
I'll stay here  for a while:
https://www.pinterest.com/soren19/arqbrt/


On 13 April 2017 at 13:31, alister  wrote:
>
> I expect you could simulate most of these with a custom exception
> for example break from nested loop:
>
> class GoTo(Exception):
> pass
>
> try:
> for i in range(100):
> print i
> for j in range (50):
> print j
> if i*j>60:
> raise GoTo
> except GoTo:
> print "Exit Early"
> print "end of loop"
>

Now I wonder, have we already collected *all* bells and whistles of Python
in these two examples, or is there something else for expressing trivial thing.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Marko Rauhamaa]

Chris Angelico :

> Personally, I can't remember the last time I yearned for "goto" in
> Python, and the only times I've ever wished for it or used it in other
> languages have been multi-loop breaks or "for...else" blocks. And
> neither is very frequent.

I have occasionally felt the urge to try "goto" in my C code, but having
written it, I have taken it out. It just doesn't make the code look more
elegant or robust. Unlike "break" or "return," "goto" makes me uneasy
about variable scope and lifetime.

Maybe it would work in some state machine implementation. Some 30 years
ago I wrote a compiler. The parser came out nicer with methodical use of
"goto," but even then, I used a parsing-specific macro to wrap it.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Ian Kelly]

On Thu, Apr 13, 2017 at 8:52 AM, bartc  wrote:
> On 13/04/2017 15:35, Chris Angelico wrote:
>> Personally, I can't remember the last time I yearned for "goto" in
>> Python, and the only times I've ever wished for it or used it in other
>> languages have been multi-loop breaks or "for...else" blocks. And
>> neither is very frequent.
>
>
> It might be a better idea to have a multi-level loop break then. This would
> also be an absolute jump byte-code.

This has previously been proposed and rejected:
https://www.python.org/dev/peps/pep-3136/
Rejection notice:
https://mail.python.org/pipermail/python-3000/2007-July/008663.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[bartc]

On 13/04/2017 15:35, Chris Angelico wrote:

On Thu, Apr 13, 2017 at 9:31 PM, alister  wrote:

I expect you could simulate most of these with a custom exception
for example break from nested loop:

class GoTo(Exception):
pass

try:
for i in range(100):
print i
for j in range (50):
print j
if i*j>60:
raise GoTo
except GoTo:
print "Exit Early"
print "end of loop"


Or you could turn it into a function and "return". Or if you feel like
it, you could turn the nested loops into a generator, then iterate
over it and break when you need to.


I know this isn't the Python need-for-speed thread, but this is a 
classic example where the lack of one simple feature leads to using 
slower, more cumbersome ones.


'goto' would be one easy-to-execute byte-code; no variables, objects or 
types to worry about. If implemented properly (with the byte-code 
compiler using a dedicated name-space for labels) there would be no name 
lookups.


Function calls, returns and generators are rather more heavyweight in 
comparison.


 There are many things you CAN do,

but to the true goto-aficionado, none of them is as clean.

Personally, I can't remember the last time I yearned for "goto" in
Python, and the only times I've ever wished for it or used it in other
languages have been multi-loop breaks or "for...else" blocks. And
neither is very frequent.


It might be a better idea to have a multi-level loop break then. This 
would also be an absolute jump byte-code.


--
bartc



--
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Chris Angelico]

On Thu, Apr 13, 2017 at 9:31 PM, alister  wrote:
> I expect you could simulate most of these with a custom exception
> for example break from nested loop:
>
> class GoTo(Exception):
> pass
>
> try:
> for i in range(100):
> print i
> for j in range (50):
> print j
> if i*j>60:
> raise GoTo
> except GoTo:
> print "Exit Early"
> print "end of loop"

Or you could turn it into a function and "return". Or if you feel like
it, you could turn the nested loops into a generator, then iterate
over it and break when you need to. There are many things you CAN do,
but to the true goto-aficionado, none of them is as clean.

Personally, I can't remember the last time I yearned for "goto" in
Python, and the only times I've ever wished for it or used it in other
languages have been multi-loop breaks or "for...else" blocks. And
neither is very frequent.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[alister]

On Thu, 13 Apr 2017 01:42:01 +0200, Mikhail V wrote:

> On 12 April 2017 at 02:44, Nathan Ernst  wrote:
>> goto is a misunderstood and much misaligned creature. It is a very
>> useful feature, but like nearly any programming construct can be
>> abused.
>>
>> Constructs like 'break', 'continue' or 'next' in languages like Python
>> or C/C++ are goto's with implied labels.
>>
>> As Mikhail said, goto's can be great to break out of nested loops (only
>> a handful of languages support named 'breaks').
>>
>> So, instead of:
>> bool found = false;
>> for (int i = 0; i = ...; ++i)
>> {
>>  for (int h = 0; h = ...; ++h)
>>  {
>>if (some_condition)
>>  found = true;
>>  }
>>  if (found) break;
>> }
>>
>> You can have:
>>
>> for (int i = 0; i = ...; ++i)
>> {
>>  for (int h = 0; h = ...; ++h)
>>  {
>>if (some_condition)
>>  goto found;
>>  }
>> }
>> // not found
>>
>> found:
>> // handle found
>>
>> The second is better for a number of reasons: it's clearer. It has
>> fewer variables (smaller stack), it has fewer branches (better for the
>> CPU's branch prediction), and it has fewer instructions (better for CPU
>> instruction cache).  This is a trivial, contrived example, but I've
>> seen more than 4x nested loops using an exit flag like this (at every
>> level of the loops) that could have been replaced with a lot less code.
>>
>> People need to stop drinking "X is considered harmful." Even Dijkstra
>> later lamented that his "Goto considered harmful" paper was
>> misinterpreted and misrepresented as advocating that goto should never
>> be used.
>>
>> Additionally, I'd recommend everyone read '"Considered Harmful" Essays
>> Considered Harmful': http://meyerweb.com/eric/comment/chech.html
>>
>> Regards,
>> Nate
>>
>>
> 
> 
> Here are recent related discussions about exiting from nested loops (at
> least seems to be so):
> https://mail.python.org/pipermail/python-ideas/2017-March/044932.html
> https://mail.python.org/pipermail/python-ideas/2017-March/045049.html
> 
> I personally have difficulties to fully understand some of the examples
> given in those proposals, namely that proposals were thought for
> other(?) purposes also,
> not only breaking nested loops.
> 
> At a first glance it seems to me that "goto" would solve the nested
> breaking problem and in a nice flexible way.
> (correct  me if I am wrong, probably I'm missing something)
> 
> So besides nested loops, in my practice I had occasions when I would
> want to use "goto".
> It would be fair to say that those occasions are not so common,
> but I'll try to give an example. Say, there is some pure procedural
> processing for some simple task and I don't want to make the script
> heavy and just care for the clarity:
> 
> ===
> Log = ""
> S = "lorem ipsum"
> 
> for s in S:
> if s == "i" :
> message = "found on stage 1"
> goto .output
> 
> S = S + " hello world"
> for s in S:
> if s == "d" :
> message = "found on stage 2"
> goto .output
> 
> print "not found"
> print "S = ", S goto .exit
> 
> .output print message Log = Log + message
> 
> .exit:
> print "exiting"
> =
> 
> For me it looks clear and I'd say easy to comprehend,
> Main critic would be obviously that it is not a good, *scalable
> application*, but quite often I don't even have this in mind, and just
> want to express a step-by-step direct instructions.
> In this case sticking any "def():.." inside the script does not make any
> sense for me. Simplicity here reflects the fact that this code
> represents exactly what I want the computer to do.
> 
> And a working variant of this would be like:
> 
> ===
> Log = ""
> found = False Error = False S = "lorem ipsum"
> 
> if not found:
> for s in S:
> if s == "i" :
> message = "found on stage 1"
> found = True
> 
> if not found:
> S = S + " hello world" for s in S:
> if s == "d" :
> message = "found on stage 2"
> found = True
> 
> if not found:
> Error = True print "Error : not found"
> print "S = ", S
> 
> 
> if not Error:
> print message Log = Log + message
> 
> print "exiting"
> ==
> 
> This is working code, but I would say there is a lot extra indentation,
> and if I don't care about application scalability, those are just adding
> noise and I it needs some boolean flags.
> 
> I am not sure what examples to add here ...
> it seems to me that e.g. if I would use Python for modelling "pipeline"
> algorithms this could be helpful also.
> 
> Now if I count in the nested loops breaking problematic,
> seems that there is at least a prerequisite for existence of "goto". Am
> I right?
> 
> 
> Mikhail

I expect you could simulate most of these with a custom exception
for example break from nested loop:

class GoTo(Exception):
pass

try:
for i in range(100):
print i
for j in range (50):
print j
if i*j>60:
   

Re: "Goto" statement in Python

[Rob Gaddi]

On 04/12/2017 04:42 PM, Mikhail V wrote:

On 12 April 2017 at 02:44, Nathan Ernst  wrote:

goto is a misunderstood and much misaligned creature. It is a very useful
feature, but like nearly any programming construct can be abused.

Constructs like 'break', 'continue' or 'next' in languages like Python or
C/C++ are goto's with implied labels.

As Mikhail said, goto's can be great to break out of nested loops (only a
handful of languages support named 'breaks').

So, instead of:
bool found = false;
for (int i = 0; i = ...; ++i)
{
 for (int h = 0; h = ...; ++h)
 {
   if (some_condition)
 found = true;
 }
 if (found) break;
}

You can have:

for (int i = 0; i = ...; ++i)
{
 for (int h = 0; h = ...; ++h)
 {
   if (some_condition)
 goto found;
 }
}
// not found

found:
// handle found

The second is better for a number of reasons: it's clearer. It has fewer
variables (smaller stack), it has fewer branches (better for the CPU's
branch prediction), and it has fewer instructions (better for CPU
instruction cache).  This is a trivial, contrived example, but I've seen
more than 4x nested loops using an exit flag like this (at every level of
the loops) that could have been replaced with a lot less code.

People need to stop drinking "X is considered harmful." Even Dijkstra later
lamented that his "Goto considered harmful" paper was misinterpreted and
misrepresented as advocating that goto should never be used.

Additionally, I'd recommend everyone read '"Considered Harmful" Essays
Considered Harmful': http://meyerweb.com/eric/comment/chech.html

Regards,
Nate





Here are recent related discussions about exiting from
nested loops (at least seems to be so):
https://mail.python.org/pipermail/python-ideas/2017-March/044932.html
https://mail.python.org/pipermail/python-ideas/2017-March/045049.html

I personally have difficulties to fully understand some
of the examples given in those proposals, namely
that proposals were thought for other(?) purposes also,
not only breaking nested loops.

At a first glance it seems to me that "goto" would solve
the nested breaking problem and in a nice flexible way.
(correct  me if I am wrong, probably I'm missing something)

So besides nested loops, in my practice I had occasions
when I would want to use "goto".
It would be fair to say that those occasions are not so common,
but I'll try to give an example. Say, there is some
pure procedural processing for some simple task
and I don't want to make the script heavy and just
care for the clarity:

===
Log = ""
S = "lorem ipsum"

for s in S:
if s == "i" :
message = "found on stage 1"
goto .output

S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
goto .output

print "not found"
print "S = ", S
goto .exit

.output
print message
Log = Log + message

.exit:
print "exiting"
=

For me it looks clear and I'd say easy to comprehend,
Main critic would be obviously that it is not
a good, *scalable application*, but quite often I don't
even have this in mind, and just want to express a
step-by-step direct instructions.
In this case sticking any "def():.." inside the script
does not make any sense for me. Simplicity here
reflects the fact that this code represents
exactly what I want the computer to do.

And a working variant of this would be like:

===
Log = ""
found = False
Error = False
S = "lorem ipsum"

if not found:
for s in S:
if s == "i" :
message = "found on stage 1"
found = True

if not found:
S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
found = True

if not found:
Error = True
print "Error : not found"
print "S = ", S


if not Error:
print message
Log = Log + message

print "exiting"
==

This is working code, but I would say there is
a lot extra indentation, and if I don't care about
application scalability, those are just adding noise
and I it needs some boolean flags.

I am not sure what examples to add here ...
it seems to me that e.g. if I would use Python
for modelling "pipeline" algorithms
this could be helpful also.

Now if I count in the nested loops breaking problematic,
seems that there is at least a prerequisite for existence of "goto".
Am I right?


Mikhail



def finder:
  for s in S:
if s == 'i':
  return 'found on stage 1'

  S = S + ' hello world'
  for s in S:
if s == 'd':
  return 'found on stage 2'

  raise ValueError('not found; S=' + S)

try:
  message = finder()
  print(message)
  log += message
except ValueError as e:
  print(e)


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list

"Goto" statement in Python

[Mikhail V]

On 12 April 2017 at 02:44, Nathan Ernst  wrote:
> goto is a misunderstood and much misaligned creature. It is a very useful
> feature, but like nearly any programming construct can be abused.
>
> Constructs like 'break', 'continue' or 'next' in languages like Python or
> C/C++ are goto's with implied labels.
>
> As Mikhail said, goto's can be great to break out of nested loops (only a
> handful of languages support named 'breaks').
>
> So, instead of:
> bool found = false;
> for (int i = 0; i = ...; ++i)
> {
>  for (int h = 0; h = ...; ++h)
>  {
>if (some_condition)
>  found = true;
>  }
>  if (found) break;
> }
>
> You can have:
>
> for (int i = 0; i = ...; ++i)
> {
>  for (int h = 0; h = ...; ++h)
>  {
>if (some_condition)
>  goto found;
>  }
> }
> // not found
>
> found:
> // handle found
>
> The second is better for a number of reasons: it's clearer. It has fewer
> variables (smaller stack), it has fewer branches (better for the CPU's
> branch prediction), and it has fewer instructions (better for CPU
> instruction cache).  This is a trivial, contrived example, but I've seen
> more than 4x nested loops using an exit flag like this (at every level of
> the loops) that could have been replaced with a lot less code.
>
> People need to stop drinking "X is considered harmful." Even Dijkstra later
> lamented that his "Goto considered harmful" paper was misinterpreted and
> misrepresented as advocating that goto should never be used.
>
> Additionally, I'd recommend everyone read '"Considered Harmful" Essays
> Considered Harmful': http://meyerweb.com/eric/comment/chech.html
>
> Regards,
> Nate
>



Here are recent related discussions about exiting from
nested loops (at least seems to be so):
https://mail.python.org/pipermail/python-ideas/2017-March/044932.html
https://mail.python.org/pipermail/python-ideas/2017-March/045049.html

I personally have difficulties to fully understand some
of the examples given in those proposals, namely
that proposals were thought for other(?) purposes also,
not only breaking nested loops.

At a first glance it seems to me that "goto" would solve
the nested breaking problem and in a nice flexible way.
(correct  me if I am wrong, probably I'm missing something)

So besides nested loops, in my practice I had occasions
when I would want to use "goto".
It would be fair to say that those occasions are not so common,
but I'll try to give an example. Say, there is some
pure procedural processing for some simple task
and I don't want to make the script heavy and just
care for the clarity:

===
Log = ""
S = "lorem ipsum"

for s in S:
if s == "i" :
message = "found on stage 1"
goto .output

S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
goto .output

print "not found"
print "S = ", S
goto .exit

.output
print message
Log = Log + message

.exit:
print "exiting"
=

For me it looks clear and I'd say easy to comprehend,
Main critic would be obviously that it is not
a good, *scalable application*, but quite often I don't
even have this in mind, and just want to express a
step-by-step direct instructions.
In this case sticking any "def():.." inside the script
does not make any sense for me. Simplicity here
reflects the fact that this code represents
exactly what I want the computer to do.

And a working variant of this would be like:

===
Log = ""
found = False
Error = False
S = "lorem ipsum"

if not found:
for s in S:
if s == "i" :
message = "found on stage 1"
found = True

if not found:
S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
found = True

if not found:
Error = True
print "Error : not found"
print "S = ", S


if not Error:
print message
Log = Log + message

print "exiting"
==

This is working code, but I would say there is
a lot extra indentation, and if I don't care about
application scalability, those are just adding noise
and I it needs some boolean flags.

I am not sure what examples to add here ...
it seems to me that e.g. if I would use Python
for modelling "pipeline" algorithms
this could be helpful also.

Now if I count in the nested loops breaking problematic,
seems that there is at least a prerequisite for existence of "goto".
Am I right?


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Mikhail 'Xen' Kashkin]

If you use ssh, then you must to learn 'scp'. Or buy books about
programming ;)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[jfouhy]

Maxim Kasimov wrote:
  Maxim Kasimov [EMAIL PROTECTED] writes:
 WOW, just greate! ... but i'd like to relax at some more
 interesting way than to comment each of rows
 but what if i just can't to do this becouse i'm working thrue ssh,
and have to
 use only installed editors (such as vi)

A slightly less arcane way of commenting out multiple lines in vi:

To comment out the current line, and the next 5:

:,+5s/^/#/

explanation:

:x,y -- specifies a line range.  If x is omitted, start with the
current line.  If y is +z, interpret it as z lines below the current
line.

^ -- regular expression matching the start of the line.

s/foo/bar/  -- replace foo with bar.

so s/^/#/ replaces the start of the line with the # character.

You can undo this with :,+5s/^#// which replaces a # at the start of
the line with the empty string (ie: deletes it).

HTH.

-- 
John.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[jfouhy]

Tim Daneliuk wrote:
 OK - Here's some reasoning that may illuminate it.  We could, in
theory,
 reduce any language to the minimal Boehm  Jacopini control
structures
 (iirc there were only four).  In effect, anything beyond these is
 syntactic sugar.  IOW, feel free to use a minimalist Turing Machine
 to implement your next 100,000 line program.

Now, how does it go ...

#!/usr/bin/env python

_pc = 1
while True:
if _pc == 1:
# statement 1
_pc = _pc + 1
elif _pc == 2:
# statement 2
_pc = _pc + 1
elif pc == 3:
# statement 3
_pc = 17   # GOTO 17
elif pc == 4:
# statement 4
_pc = _pc + 1
...
else:
# Fallen off the end of our program.
break

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Mike Meyer]

Grant Edwards [EMAIL PROTECTED] writes:

 On 2005-04-21, Roy Smith [EMAIL PROTECTED] wrote:
 Grant Edwards  [EMAIL PROTECTED] wrote:
Sure, but what about the case where his program is on paper
tape and all he has for an editor is an ice pick?

 Can't you emulate that in emacs with M-X inclusive-or-overwrite-mode?

 Heck, emacs probably has a paper-tape-mode where it displays
 the file like this:

   ooo.
   ooo.
   ooo.
   ooo.
   o o.o  o
   o o.oo
oo.  oo
   o  .oo o
   ooo.
 o.oo
oo.oo o
   o o.o oo
   o  .ooo

I can't find it in Emacs. On the other hand:

guru% /usr/games/ppt emacs rulez!
___
| oo  .o o|
| oo o.o o|
| oo  .  o|
| oo  . oo|
| ooo . oo|
| ooo . o |
| ooo .o o|
| oo o.o  |
| oo  .o o|
| . o |
|  o  .  o|
___
guru% 

and

guru% /usr/games/bcd vi rulez!
 
/VI  |
| ]  |
||
|]   |
||
||
||
||
|]555|
||
||
||
|9]99|
||
 
/RULEZ!  |
|   ]|
|] ] |
| ]  ]]  |
||
||
|33]3|
|4]44|
|555]|
||
|7]77|
|8]88|
|]999]999|
||
guru% 

and just for grins:

guru% /usr/games/morse ed rulez!
 dit
 dah dit dit

 dit dah dit
 dit dit dah
 dit dah dit dit
 dit
 dah dah dit dit
 dit dit dah dah dit

guru% 

So adding paper-tape mode to emacs shouldn't be all that hard.

  mike
-- 
Mike Meyer [EMAIL PROTECTED]  http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Reinhold Birkenfeld]

Grant Edwards wrote:
 On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:
 
 Well, I'm writing for embedded realtime systems in C/C++ and
 have never encountered a single need to use goto.
 
 I have encountered situations in C programs where the best
 thing to use was a goto.  Those situations have always been
 handled beutifully by a raise in Python.

 setjmp/longjump?
 
 I've always found setjmp/longjmp much more confusing and hard
 to maintain than a simple goto.  It also requires library
 support that goto doesn't.

 Agreed. The 'goto error' idiom is in fact the only goto usage
 I do agree with provided there is no support for exceptions,
 but that's not applicable to Python anyway.
 
 Exactly.  I've been writing C code for 20+ years, and the only
 problems where I found goto to be a good solution are the ones
 where exceptions are even better solutions in Python.  I've
 never found myself wishing for a goto when writing Python code.

The Python C source code is full of such gotos, it must be good
practise...

Reinhold
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Reinhold Birkenfeld]

Grant Edwards wrote:
 On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:
 Grant Edwards [EMAIL PROTECTED] writes:

 On 2005-04-21, Peter Maas [EMAIL PROTECTED] wrote:
  Maxim Kasimov schrieb:
  but what if i just can't to do this becouse i'm working thrue ssh, and 
  have to use only installed editors (such as vi)
 
  - at first line of block enter: ma (mark line as 'a')
  - go to last line of block
  - enter :'a,.s/^/###/ (insert 3 comment chars at begin of line,
 starting from line marked as 'a' to current line)
 
 Sure, but what about the case where his program is on paper
 tape and all he has for an editor is an ice pick?

 Then inserting goto doesn't seem to be an acceptable option either ;)
 
 Scissors, tape, and a box full of prepunched goto and label
 statements.  Of course you could do the same with a bunch of
 pre-punched  tape-chunks.

Why? You just cut out the piece of paper you want to comment, put it in
your drawer labeled comments, and insert it again when you need it.

Reinhold
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Grant Edwards]

On 2005-04-22, Reinhold Birkenfeld [EMAIL PROTECTED] wrote:

 Sure, but what about the case where his program is on paper
 tape and all he has for an editor is an ice pick?

 Then inserting goto doesn't seem to be an acceptable option
 either ;)
 
 Scissors, tape, and a box full of prepunched goto and
 label statements.  Of course you could do the same with a
 bunch of pre-punched  tape-chunks.

 Why? You just cut out the piece of paper you want to comment,
 put it in your drawer labeled comments, and insert it again
 when you need it.

I'd never be able to find it when I needed to put it back in. :)

-- 
Grant Edwards   grante Yow!  Like I always
  at   say -- nothing can beat
   visi.comthe BRATWURST here in
   DUSSELDORF!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Peter Hansen]

Grant Edwards wrote:
Sure, but what about the case where his program is on paper
tape and all he has for an editor is an ice pick?
Paper tape?  Luxury
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maxim Kasimov]

1. comment for debug
   It can be used in the same way, as the comments for debugging are used, but it will be 
easier than to use  or ''', or using features of text-editors,
   when it is necessary to comment piece of code which already contains ''' or/and 
 strings already, or there is another #-comments.
   Using goto, you do not need to edit a code, which is unfamiliar to you.
2. obfuscators
   goto can be used in the same way, as many of java-obfuscators do
Speaking in other words:
  1) goto exempts from necessity to install new software (it is critical for 
remote working, for example, installing X11 may be impossible at all)
  2) enables to make new, better software (better obfuscators)
--
Best regards,
Maxim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Tim Daneliuk]

Reinhold Birkenfeld wrote:
John Bokma wrote:
Mage wrote:

praba kar wrote:

Dear All,
 In Python what is equivalent to goto statement

You shouldn't use goto in high-level languages.
Nonsense
+1

Thank you!
Above all your claim is well justified. These brilliant arguments
you have put forth really explain in a magnificent way why goto is a
sane addition to any HLL.
Reinhold
OK - Here's some reasoning that may illuminate it.  We could, in theory,
reduce any language to the minimal Boehm  Jacopini control structures
(iirc there were only four).  In effect, anything beyond these is
syntactic sugar.  IOW, feel free to use a minimalist Turing Machine
to implement your next 100,000 line program.
I, on the other hand, have a really hard time finding infinite tapes (in
both directions) and a suitably fast tape reader to implement such
ideas. (I also seem to recall that any digital circuit can be
implemented with nothing more than AND and NOT gates, but I'd rather
not, thanks - I don't have enough probes on my oscilloscope to debug
that kind of hardware.)
Control structures/directives evolve to solve real problems. 'goto',
properly used, can actually clarify code, especially when dealing with
exceptions and the like. Oh, we may rename it and call it 'break' or
'try/except' or whatever suits the language author's fancy, but the
concept is similar, if not identical.  'goto' certainly could be
synthesized in Python with the appropriate try/except hierarchy
and custom exceptions, but in many cases this would *really* be overkill -
a simple 'goto' would be considerably simpler *and* probably easier
to understand.  Note that I am not arguing for 'goto' in Python,
merely trying to respond to your point about why it is does not inherently
appropriate for HLLs.
Some HLLs almost have to have it by definition.  I cut my teeth as programmer
writing for embedded realtime systems in a HLL (PL/M).  While you could,
in theory, completely avoid 'goto' in a realtime environment, it would
make all manner of practical programming problems kind of ugly to implement.
BTW, all modern systems come complete with 'goto' implemented in
*hardware* - they're called interrupts.
More to the point, I have seen some really tortured code written in the
name of maintaining religious purity of some kind (Structure, Object
Orientation,...). While language constructs can promote better- or
worse code structuring, at the end of the day, programming is still the
expression of human thought. Some people think clearly, some don't, and
this has little to do with just what language structures are in use.
Python is elegant at almost every level, and I am certainly not
arguing for 'goto' in the language.  But to reflexively assume that
it has *no* place in a modern HLL is, I think, a bit overstated.
I must now 'goto' sleep ... and I cannot think of a better way
to express this...
--

Tim Daneliuk [EMAIL PROTECTED]
PGP Key: http://www.tundraware.com/PGP/
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Reinhold Birkenfeld]

Maxim Kasimov wrote:

1) goto exempts from necessity to install new software
 (it is critical for remote working, for example, installing X11 may be
 impossible at all)

Attributing the need for a language feature to restrictions of your ambience
is hilarious.

Reinhold
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Sergei Organov]

Maxim Kasimov [EMAIL PROTECTED] writes:

 1. comment for debug
 
 It can be used in the same way, as the comments for debugging are
 used, but it will be easier than to use  or ''', or using
 features of text-editors, when it is necessary to comment piece of
 code which already contains ''' or/and  strings already, or
 there is another #-comments. Using goto, you do not need to edit a
 code, which is unfamiliar to you.

... and then you end up with situation when another goto jumps directly
into the body of the code you've just commented with your goto. Happy
debugging!

BTW, don't you want comefrom statement to be added to the language
to make debugging even more fun?

-- 
Sergei.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Sergei Organov]

Tim Daneliuk [EMAIL PROTECTED] writes:

[...]

 Some HLLs almost have to have it by definition.  I cut my teeth as programmer
 writing for embedded realtime systems in a HLL (PL/M).  While you could,
 in theory, completely avoid 'goto' in a realtime environment, it would
 make all manner of practical programming problems kind of ugly to implement.
 BTW, all modern systems come complete with 'goto' implemented in
 *hardware* - they're called interrupts.

Well, I'm writing for embedded realtime systems in C/C++ and have never
encountered a single need to use goto. Comparing interrupts to goto
doesn't make any sense for me either. For example, most architectures
have 'branch' *hardware* instructions that are much more close
equivalents to goto than interrupts are, but that doesn't justify use of
goto in high-level languages in any way.

-- 
Sergei.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Diez B. Roggisch]

 implement. BTW, all modern systems come complete with 'goto' implemented
 in *hardware* - they're called interrupts.

That's not goto - that is a asynchronous function call - much closer related
to multithreading.

In an interrupt, you can always jump back to the main program using rte
(return from interrupt) - or whatever that is called on the respective
processor.

Of course you _can_ alter all sorts of state, including the stackframe and
the PC when inside an interrupt - thus you can create goto for e.g.
multithreading. But I wouldn't call that builtin-goto...


-- 
Regards,

Diez B. Roggisch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maxim Kasimov]

Sergei Organov wrote:
Maxim Kasimov [EMAIL PROTECTED] writes:

1. comment for debug
   It can be used in the same way, as the comments for debugging are
   used, but it will be easier than to use  or ''', or using
   features of text-editors, when it is necessary to comment piece of
   code which already contains ''' or/and  strings already, or
   there is another #-comments. Using goto, you do not need to edit a
   code, which is unfamiliar to you.

 and then you end up with situation when another goto jumps directly
into the body of the code you've just commented with your goto. Happy
debugging!
BTW, don't you want comefrom statement to be added to the language
to make debugging even more fun?
if you can't control what you do - it is you private problem, not mine. 
Is't it?
--
Best regards,
Maxim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Grant Edwards]

On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:

 Well, I'm writing for embedded realtime systems in C/C++ and
 have never encountered a single need to use goto.

I have encountered situations in C programs where the best
thing to use was a goto.  Those situations have always been
handled beutifully by a raise in Python.

 Comparing interrupts to goto doesn't make any sense for me
 either. For example, most architectures have 'branch'
 *hardware* instructions that are much more close equivalents
 to goto than interrupts are, but that doesn't justify use of
 goto in high-level languages in any way.

I agree.  The jump or branch instruction corresponds
exactly to a goto.  An interrupt is more like a signal and a
signal handler in C.  Sort of like an asynchronous function
call or thread context switch.

-- 
Grant Edwards   grante Yow!  Now that we're
  at   in LOVE, you can BUY
   visi.comthis GOLDFISH for a 48%
   DISCOUNT.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[John Bokma]

Do Re Mi chel La Si Do wrote:

 +1

I am modded up :-D

-- 
John   MexIT: http://johnbokma.com/mexit/
   personal page:   http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[John Bokma]

Reinhold Birkenfeld wrote:

 John Bokma wrote:
 Mage wrote:
 
 praba kar wrote:
 
Dear All,

   In Python what is equivalent to goto statement

  

 You shouldn't use goto in high-level languages.
 
 Nonsense
 
 Thank you!
 
 Above all your claim is well justified.

You are probably smart enough to think of several situations that 
justify the use of a goto (or something that is a goto in disguise, like 
an early return in a function, a break or a continue, or a switch).

One can abuse a goto in any language, like every other language 
construction. But don't make it a shouldn't like a law.

Some people take Dijkstra too serious. Learn to think for yourself, I am 
sure he did.

-- 
John   MexIT: http://johnbokma.com/mexit/
   personal page:   http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Mage]

Michael Soulier wrote:

On 4/20/05, Maxim Kasimov [EMAIL PROTECTED] wrote:
  

but what if i just can't to do this becouse i'm working thrue ssh, and have 
to use 
only installed editors (such as vi)



Then learn to use vi. 

:.,+10s/^/#
 comment the next 10 lines
  

Or if you don't like that you can use sftpfs with gui editor.

   Mage
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Sergei Organov]

Maxim Kasimov [EMAIL PROTECTED] writes:
 Sergei Organov wrote:
  Maxim Kasimov [EMAIL PROTECTED] writes:
 
 
 1. comment for debug
 
 It can be used in the same way, as the comments for debugging are used,
 but it will be easier than to use  or ''', or using features of
 text-editors, when it is necessary to comment piece of code which already
 contains ''' or/and  strings already, or there is another #-comments.
 Using goto, you do not need to edit a code, which is unfamiliar to
 you.

   and then you end up with situation when another goto jumps directly
  into the body of the code you've just commented with your goto. Happy
  debugging!

 if you can't control what you do - it is you private problem, not mine. Is't
 it?

Hopefully I do control what I do. However, wasn't it you who spoke about
code, which is unfamiliar? Obviously you advocate using goto to
comment out a code that has been written by somebody else. I don't see
any way for you or me to control what those somebody did with goto
provided that goto is there in the language, sorry.

Overall, using goto for commenting something out is not any better than
 or ''', as the code to be commented out could contain labels and you
will need to find and comment out all the goto that jump to these labels
as well. Happy debugging!

-- 
Sergei.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Sergei Organov]

Grant Edwards [EMAIL PROTECTED] writes:

 On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:
 
  Well, I'm writing for embedded realtime systems in C/C++ and
  have never encountered a single need to use goto.
 
 I have encountered situations in C programs where the best
 thing to use was a goto.  Those situations have always been
 handled beutifully by a raise in Python.

setjmp/longjump?

-- 
Sergei.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Grant Edwards]

On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:
 Grant Edwards [EMAIL PROTECTED] writes:

 On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:
 
  Well, I'm writing for embedded realtime systems in C/C++ and
  have never encountered a single need to use goto.
 
 I have encountered situations in C programs where the best
 thing to use was a goto.  Those situations have always been
 handled beutifully by a raise in Python.

 setjmp/longjump?

I've always found setjmp/longjmp much more confusing and hard
to maintain than a simple goto.  It also requires library
support that goto doesn't.

-- 
Grant Edwards   grante Yow!  Your CHEEKS sit like
  at   twin NECTARINES above
   visi.coma MOUTH that knows no
   BOUNDS --
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Sergei Organov]

Grant Edwards [EMAIL PROTECTED] writes:

 On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:
  Grant Edwards [EMAIL PROTECTED] writes:
 
  On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:
  
   Well, I'm writing for embedded realtime systems in C/C++ and
   have never encountered a single need to use goto.
  
  I have encountered situations in C programs where the best
  thing to use was a goto.  Those situations have always been
  handled beutifully by a raise in Python.
 
  setjmp/longjump?
 
 I've always found setjmp/longjmp much more confusing and hard
 to maintain than a simple goto.  It also requires library
 support that goto doesn't.

Agreed. The 'goto error' idiom is in fact the only goto usage I do
agree with provided there is no support for exceptions, but that's not
applicable to Python anyway.

-- 
Sergei.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Peter Maas]

Maxim Kasimov schrieb:
but what if i just can't to do this becouse i'm working thrue ssh, and 
have to use only installed editors (such as vi)
- at first line of block enter: ma (mark line as 'a')
- go to last line of block
- enter :'a,.s/^/###/ (insert 3 comment chars at begin of line,
  starting from line marked as 'a' to current line)
:)
--
---
Peter Maas,  M+R Infosysteme,  D-52070 Aachen,  Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
---
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Grant Edwards]

On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:

 Well, I'm writing for embedded realtime systems in C/C++ and
 have never encountered a single need to use goto.
 
 I have encountered situations in C programs where the best
 thing to use was a goto.  Those situations have always been
 handled beutifully by a raise in Python.

 setjmp/longjump?
 
 I've always found setjmp/longjmp much more confusing and hard
 to maintain than a simple goto.  It also requires library
 support that goto doesn't.

 Agreed. The 'goto error' idiom is in fact the only goto usage
 I do agree with provided there is no support for exceptions,
 but that's not applicable to Python anyway.

Exactly.  I've been writing C code for 20+ years, and the only
problems where I found goto to be a good solution are the ones
where exceptions are even better solutions in Python.  I've
never found myself wishing for a goto when writing Python code.

-- 
Grant Edwards   grante Yow!  It's hard being
  at   an ARTIST!!
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Grant Edwards]

On 2005-04-21, Peter Maas [EMAIL PROTECTED] wrote:
 Maxim Kasimov schrieb:
 but what if i just can't to do this becouse i'm working thrue ssh, and 
 have to use only installed editors (such as vi)

 - at first line of block enter: ma (mark line as 'a')
 - go to last line of block
 - enter :'a,.s/^/###/ (insert 3 comment chars at begin of line,
starting from line marked as 'a' to current line)

Sure, but what about the case where his program is on paper
tape and all he has for an editor is an ice pick?

-- 
Grant Edwards   grante Yow!  Kids, don't gross me
  at   off... Adventures with
   visi.comMENTAL HYGIENE can be
   carried too FAR!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Roy Smith]

Grant Edwards  [EMAIL PROTECTED] wrote:
Sure, but what about the case where his program is on paper
tape and all he has for an editor is an ice pick?

Can't you emulate that in emacs with M-X inclusive-or-overwrite-mode?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Sergei Organov]

Grant Edwards [EMAIL PROTECTED] writes:

 On 2005-04-21, Peter Maas [EMAIL PROTECTED] wrote:
  Maxim Kasimov schrieb:
  but what if i just can't to do this becouse i'm working thrue ssh, and 
  have to use only installed editors (such as vi)
 
  - at first line of block enter: ma (mark line as 'a')
  - go to last line of block
  - enter :'a,.s/^/###/ (insert 3 comment chars at begin of line,
 starting from line marked as 'a' to current line)
 
 Sure, but what about the case where his program is on paper
 tape and all he has for an editor is an ice pick?

Then inserting goto doesn't seem to be an acceptable option either ;)

-- 
Sergei.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[pythonUser_07]

Hi,

Have you tried the triple quote comment technique?

I am assuming you want to skip some code for the time being.

Here is an example

print hello world
''' COMMENT OUT FOR NOW
someFunction()
someOtherFunction()
'''
print goodbye world

This means that you have only two locations to remove the blocked out
code.  This is identical to having to remove the goto statement and the
marker.

Hope that helps.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maxim Kasimov]

pythonUser_07 wrote:
Hi,
Have you tried the triple quote comment technique?
I am assuming you want to skip some code for the time being.
Here is an example
print hello world
''' COMMENT OUT FOR NOW
someFunction()
someOtherFunction()
'''
print goodbye world
This means that you have only two locations to remove the blocked out
code.  This is identical to having to remove the goto statement and the
marker.
Hope that helps.
how do use this here:
print hello world
...
...
...
sql = '''
some long query
'''
...
...
...
sql = 
another query

...
...
...
print goodbye world


--
Best regards,
Maxim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Fredrik Lundh]

Maxim Kasimov wrote:
how do use this here:
are you still claiming you're not a troll?
*plonk*
/F
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Mage]

Maxim Kasimov wrote:


 how do use this here:

 print hello world


There are cases when you can't do it in any language.


php:

/* this is a debug comment

function1();
function2();

/* this is a normal multiline comment block
it ends here
*/

function3();

*/ end of debug comment


/ if you don't really want to do it /

   Mage
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[R. C. James Harlow]

On Thursday 21 April 2005 17:42, Maxim Kasimov wrote:
  Have you tried the triple quote comment technique?

 how do use this here:

Simple.

 sql = '''
 some long query
 '''

Change this to:

sql = 
some long query


since you shouldn't be using multiple quoting styles in one module, any more 
than you should be using multiple casing styles.

Then just put single quotes around the place where you want to comment. Not 
hard, is it?

james.


pgpEOkrYjHYZq.pgp
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Grant Edwards]

On 2005-04-21, Roy Smith [EMAIL PROTECTED] wrote:
 Grant Edwards  [EMAIL PROTECTED] wrote:
Sure, but what about the case where his program is on paper
tape and all he has for an editor is an ice pick?

 Can't you emulate that in emacs with M-X inclusive-or-overwrite-mode?

Heck, emacs probably has a paper-tape-mode where it displays
the file like this:

  ooo.
  ooo.
  ooo.
  ooo.
  o o.o  o
  o o.oo
   oo.  oo
  o  .oo o
  ooo.
o.oo
   oo.oo o
  o o.o oo
  o  .ooo



If not, i'm sure it'll soon be added.

-- 
Grant Edwards   grante Yow!  I'm losing my
  at   hair...did it go to
   visi.comATLANTIC CITY??
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Grant Edwards]

On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:
 Grant Edwards [EMAIL PROTECTED] writes:

 On 2005-04-21, Peter Maas [EMAIL PROTECTED] wrote:
  Maxim Kasimov schrieb:
  but what if i just can't to do this becouse i'm working thrue ssh, and 
  have to use only installed editors (such as vi)
 
  - at first line of block enter: ma (mark line as 'a')
  - go to last line of block
  - enter :'a,.s/^/###/ (insert 3 comment chars at begin of line,
 starting from line marked as 'a' to current line)
 
 Sure, but what about the case where his program is on paper
 tape and all he has for an editor is an ice pick?

 Then inserting goto doesn't seem to be an acceptable option either ;)

Scissors, tape, and a box full of prepunched goto and label
statements.  Of course you could do the same with a bunch of
pre-punched  tape-chunks.

-- 
Grant Edwards   grante Yow!  Yow! Am I in
  at   Milwaukee?
   visi.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Ivan Van Laningham]

Hi All--

Fredrik Lundh wrote:
 
 Maxim Kasimov wrote:
 
  how do use this here:
 
 are you still claiming you're not a troll?
 
 *plonk*
 

Oh, I don't think he's a troll, but his license to use Python should be
revoked.  I think RPG would be a good language for him, don't you?

Metta,
Ivan
--
Ivan Van Laningham
God N Locomotive Works
http://www.andi-holmes.com/
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps:  Cu Chi, Class of '70
Author:  Teach Yourself Python in 24 Hours
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Ron]

Grant Edwards wrote:
On 2005-04-21, Sergei Organov [EMAIL PROTECTED] wrote:

Well, I'm writing for embedded realtime systems in C/C++ and
have never encountered a single need to use goto.
I have encountered situations in C programs where the best
thing to use was a goto.  Those situations have always been
handled beutifully by a raise in Python.
setjmp/longjump?
I've always found setjmp/longjmp much more confusing and hard
to maintain than a simple goto.  It also requires library
support that goto doesn't.
Agreed. The 'goto error' idiom is in fact the only goto usage
I do agree with provided there is no support for exceptions,
but that's not applicable to Python anyway.

Exactly.  I've been writing C code for 20+ years, and the only
problems where I found goto to be a good solution are the ones
where exceptions are even better solutions in Python.  I've
never found myself wishing for a goto when writing Python code.
I can remember in the early apple2+ days of trying to untangle code 
written by others with liberal use of gotos and no clear program 
structure.  A non trivial task that often meant it was easier to start 
over than to modify someone elses program. Determining the context of a 
statement often required snaking through several dozen gotos with 'line 
number's to find out what a particular section of code actually did. 
Making changes to such code could be difficult and often had unintended 
consequences.

The if, elif, else, functions, and while statements are the replacements 
for goto's.  And they make the code much more readable and 
understandable than something like ...

100 PRINT HELLO
105 INPUT  ;S$  
110 IF S$ = GOODBYE THEN GOTO 140
115 IF S$ = HOW ARE YOU THEN GOTO 150
130 GOTO 100
140 PRINT GOODBYE
145 GOTO 200
150 PRINT I'M FINE
160 GOTO 105
200 REM CONTINUE
LOL, I HAD TO... Oops caps...  look up apple soft basic to remember what 
I couldn't do.  Part of the reason for the spaghetti code was that with 
line numbers it's easier to tack on something to the end than it is to 
change all the line numbers if you didn't allow for room.  I for one, 
don't miss goto's or line numbers!  ;-)

Apple Soft Quick Refrence -
http://www.cosmicwolf.com/AppleII/applesoft_basic.htm
Cheers,
Ron
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[John Roth]

praba kar [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
Dear All,
  In Python what is equivalent to goto statement
Sheesh! It took 20 days for this to get to my mail server!
John Roth
regards,
praba
--
http://mail.python.org/mailman/listinfo/python-list

goto statement

[praba kar]

Dear All,

   In Python what is equivalent to goto statement

regards,
praba 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Mage]

praba kar wrote:

Dear All,

   In Python what is equivalent to goto statement

  

You shouldn't use goto in high-level languages.

   Mage


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Simon Brunning]

On 4/20/05, praba kar [EMAIL PROTECTED] wrote:
In Python what is equivalent to goto statement

http://docs.python.org/tut/node6.html

See, it's those dratted node numbers again. ;-)

-- 
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maurice Caret]

Simon Brunning a écrit :
On 4/20/05, praba kar [EMAIL PROTECTED] wrote:
  In Python what is equivalent to goto statement

http://docs.python.org/tut/node6.html
See, it's those dratted node numbers again. ;-)
other equivalents are in
http://docs.python.org/tut/node10.html
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Simon Brunning]

On 4/20/05, Maurice Caret [EMAIL PROTECTED] wrote:
 
 other equivalents are in
 
 http://docs.python.org/tut/node10.html

I also missed 
http://docs.python.org/tut/node5.html#SECTION00520,
for the while statement.

Those URLs just keeg getting better...

-- 
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maxim Kasimov]

Mage wrote:
praba kar wrote:

Dear All,
 In Python what is equivalent to goto statement

You shouldn't use goto in high-level languages.
it would be quite useful for debuging porposes
--
Best regards,
Maxim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Simon Brunning]

On 4/20/05, Maxim Kasimov [EMAIL PROTECTED] wrote:
 it would be quite useful for debuging porposes

How does goto help you to remove bugs?

I can certainly see how it helps you put them in in the first place...

-- 
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[John Bokma]

Mage wrote:

 praba kar wrote:
 
Dear All,

   In Python what is equivalent to goto statement

  

 You shouldn't use goto in high-level languages.

Nonsense

-- 
John   MexIT: http://johnbokma.com/mexit/
   personal page:   http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Reinhold Birkenfeld]

John Bokma wrote:
 Mage wrote:
 
 praba kar wrote:
 
Dear All,

   In Python what is equivalent to goto statement

  

 You shouldn't use goto in high-level languages.
 
 Nonsense

Thank you!

Above all your claim is well justified. These brilliant arguments
you have put forth really explain in a magnificent way why goto is a
sane addition to any HLL.

Reinhold
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maxim Kasimov]

Simon Brunning wrote:
On 4/20/05, Maxim Kasimov [EMAIL PROTECTED] wrote:
it would be quite useful for debuging porposes

How does goto help you to remove bugs?
I can certainly see how it helps you put them in in the first place...
if you need to comment a couple of code (and then uncomment ), what are you 
doing then?
--
Best regards,
Maxim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Robert Kern]

Maxim Kasimov wrote:
Simon Brunning wrote:
On 4/20/05, Maxim Kasimov [EMAIL PROTECTED] wrote:
it would be quite useful for debuging porposes

How does goto help you to remove bugs?
I can certainly see how it helps you put them in in the first place...
if you need to comment a couple of code (and then uncomment ), what are 
you doing then?
Use comments?
--
Robert Kern
[EMAIL PROTECTED]
In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die.
  -- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maxim Kasimov]

Robert Kern wrote:
Maxim Kasimov wrote:
Simon Brunning wrote:
On 4/20/05, Maxim Kasimov [EMAIL PROTECTED] wrote:
it would be quite useful for debuging porposes


How does goto help you to remove bugs?
I can certainly see how it helps you put them in in the first place...
if you need to comment a couple of code (and then uncomment ), what 
are you doing then?

Use comments?
WOW, just greate! ... but i'd like to relax at some more interesting way 
than to comment each of rows
--
Best regards,
Maxim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Reinhold Birkenfeld]

Maxim Kasimov wrote:
 Robert Kern wrote:
 Maxim Kasimov wrote:
 
 Simon Brunning wrote:

 On 4/20/05, Maxim Kasimov [EMAIL PROTECTED] wrote:

 it would be quite useful for debuging porposes




 How does goto help you to remove bugs?

 I can certainly see how it helps you put them in in the first place...


 if you need to comment a couple of code (and then uncomment ), what 
 are you doing then?
 
 
 Use comments?
 
 
 WOW, just greate! ... but i'd like to relax at some more interesting way than 
 to comment each of rows

Use multi-line string literals.

'''

This whole 'code' is commented out, and you can
use every type of quote except three singles.

'''

Or, if you really like the spirit of goto,
use if 0:.

Reinhold
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Mage]

Maxim Kasimov wrote:

 WOW, just greate! ... but i'd like to relax at some more interesting
 way than to comment each of rows

There are editors that can comment and uncomment blocks.

In worst case you can use  to comment blocks (not elegant but works).

   Mage
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: goto statement

[Sander Steffann]

On 4/20/05, praba kar [EMAIL PROTECTED] wrote:
In Python what is equivalent to goto statement

An old user-friendly cartoon that might be relevant:
http://ars.userfriendly.org/cartoons/?id=2506

Have fun :-)
Sander

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Simon Brunning]

On 4/20/05, Maxim Kasimov [EMAIL PROTECTED] wrote:
 WOW, just greate! ... but i'd like to relax at some more interesting way than 
 to comment each of rows

Get a decent text editor.

-- 
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Do Re Mi chel La Si Do]

+1



Michel Claveau



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Torsten Bronger]

Hallchen!

Maxim Kasimov [EMAIL PROTECTED] writes:

 [...]

 WOW, just greate! ... but i'd like to relax at some more
 interesting way than to comment each of rows

Then just use a good editor.

Tsch,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Michael Hoffman]

praba kar wrote:
   In Python what is equivalent to goto statement
http://groups-beta.google.com/group/comp.lang.python/msg/98264a0daa007c46
--
Michael Hoffman
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maxim Kasimov]

Use multi-line string literals.
'''
it will not help if there is another ''' or/and  inside of code block
This whole 'code' is commented out, and you can
use every type of quote except three singles.
'''
Or, if you really like the spirit of goto,
use if 0:.
... and add tabs to each string
Reinhold

--
Best regards,
Maxim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maxim Kasimov]

Torsten Bronger wrote:
Hallchen!
Maxim Kasimov [EMAIL PROTECTED] writes:

[...]
WOW, just greate! ... but i'd like to relax at some more
interesting way than to comment each of rows

but what if i just can't to do this becouse i'm working thrue ssh, and have 
to use only installed editors (such as vi)
--
Best regards,
Maxim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Simon Brunning]

On 4/20/05, Maxim Kasimov [EMAIL PROTECTED] wrote:
  Or, if you really like the spirit of goto,
  use if 0:.
 
 ... and add tabs to each string

Get a decent text editor.

What are you using? Notepad?

-- 
Cheers,
Simon B,
[EMAIL PROTECTED],
http://www.brunningonline.net/simon/blog/
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Peter Hansen]

Maxim Kasimov wrote:
Torsten Bronger wrote:
Hallchen!
Maxim Kasimov [EMAIL PROTECTED] writes:
WOW, just greate! ... but i'd like to relax at some more
interesting way than to comment each of rows
but what if i just can't to do this becouse i'm working thrue ssh, and 
have to use only installed editors (such as vi)
Surely you use more than one-character indents?  If
that's so, you can just insert the if 0: using, say,
two characters indentation instead of the usual four.
Then the following four-character-indented code is
removed.
Alternatively, use ''' and ''' surrounding the code
block and it will be ignored.
-Peter
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Maxim Kasimov]

Peter Hansen wrote:
Maxim Kasimov wrote:
Torsten Bronger wrote:
Hallchen!
Maxim Kasimov [EMAIL PROTECTED] writes:
WOW, just greate! ... but i'd like to relax at some more
interesting way than to comment each of rows

but what if i just can't to do this becouse i'm working thrue ssh, and 
have to use only installed editors (such as vi)

Surely you use more than one-character indents?  If
that's so, you can just insert the if 0: using, say,
two characters indentation instead of the usual four.
Then the following four-character-indented code is
removed.
Alternatively, use ''' and ''' surrounding the code
block and it will be ignored.
 f..., i don't requesting that goto was available in next versions of 
python,
 but i'm saying if it will be so, it will be easy and quickly _debug_ some 
skripts,
 _not only_ for commenting
--
Best regards,
Maxim Kasimov
mailto: [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Reinhold Birkenfeld]

Maxim Kasimov wrote:
 
 Use multi-line string literals.
 
 '''
 
 it will not help if there is another ''' or/and  inside of code block

Yes, but how often do you use them? And aren't you consistent in the choice
of your quotes?

 This whole 'code' is commented out, and you can
 use every type of quote except three singles.
 
 '''
 
 Or, if you really like the spirit of goto,
 use if 0:.
 
 ... and add tabs to each string

Yes. Where's the problem?

M-x indent-region-ly yours,
Reinhold
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: goto statement

[Reinhold Birkenfeld]

Maxim Kasimov wrote:

   f..., i don't requesting that goto was available in next versions of 
 python,
   but i'm saying if it will be so, it will be easy and quickly _debug_ some 
 skripts,
   _not only_ for commenting

If you want, you can always use the goto module.

Reinhold, no, I will not tell you where to find it
-- 
http://mail.python.org/mailman/listinfo/python-list