Is there a goto like there is in BASIC?

[Larz60+]

In the 70's, most microcomputer code was Basic until the advent of forth (which followed shortly thereafter)
I admit, I used it. I wanted to get things done. It was free even then! and I was poor!

I also wrote extensively in assembler (6502, 8080, 6800).
Then forth which I was passionate about.

[volcano63]

Thank God No!

Being a benevolent dictator for life does not make one a god!

That's why I thanked BDFL 

---

In the 70's, most microcomputer code was Basic until the advent of forth (which followed shortly thereafter)

In 1986 I started on a Soviet clone (pirated, of course) of Wang2200. The bloody thing didn't even have procedure/functions   . Then I had to translate it into Pascal on 48K clone of some Japanese microcomp. The joys of segmenting and overloading code

[Kebap]

I did find it useful for certain things.  One was for when I was still in the early stages of creating a loop and wanted to avoid an endless loop and a crash.  I could set an integer to track the number of times something looped, and then set a place outside the loop named "JumpOut".  If the integer got higher than 1,000 (or some other value), "GoTo JumpOut" would be triggered and the loop would end. 

(...)

Another one was "On Error Resume Next."  That was useful to keep code running while searching for errors, but I would remove it after errors were found and fixed. 

I'll keep learning.  I'm sure I'll come across a lot of great debugging tricks in time.  Thank you so much for your useful comments.

You may want to look into python break and try/except constructs

[Luke_Drillbrain]

[snip]

You may want to look into python break and try/except constructs

I'll look those up.  Thanks for the tip.

[nilamo]

One was for when I was still in the early stages of creating a loop and wanted to avoid an endless loop and a crash.  I could set an integer to track the number of times something looped, and then set a place outside the loop named "JumpOut".  If the integer got higher than 1,000 (or some other value), "GoTo JumpOut" would be triggered and the loop would end.  

I don't see how that'd be better than just writing a function and using return to get out of the function.  It's the same thing, except with the function it's easier to see what your actual intention is.

[snippsat]

If the integer got higher than 1,000 (or some other value), "GoTo JumpOut" would be triggered and the loop would end.

To add some advice to what's alreay mention
Using Function/Class can be important to think of,
example in a function you can return out.
This can be nicer than break/continue to other stuff.

A example:
So here jump to function foo,
after foo is finish it will fall back to menu which can run again or quit(return) out.

import time

def foo():
   for i in reversed(range(5)):
       time.sleep(1)
       print('Running {}'.format(i))
   input('Push enter to retun to menu')

def menu():
   while True:
       print('(1) Test someting')
       print('(Q) Quit')
       choice = input('Enter your choice: ').lower()
       if choice == '1':
           foo()
       elif choice == 'q':
           return 
       else:
           print('Not a correct choice: {}'.format(choice))

if __name__ == '__main__':
   menu()

[nilamo]

Here's an article from not that long ago detailing NASA's 10 programming rules for safety: http://www.rankred.com/nasa-coding-rules/

#1 is basically never use goto.

Rule No. 1 – Simple Control Flow
Write program with very simple control flow constructs – Do not use setjmp or longjmp constructs, goto statements, and direct or indirect recursion.

Reason: Simple control flow results in improved code clarity and stronger capabilities for verification. Without recursion, there will be no cyclic function call graph, and this proves that all executions that should be bounded are in fact bounded.

[micseydel]

Not even recursion? That's interesting....

[nilamo]

That doc is probably really old. Guaranteeing something doesn't eat too much memory while careening around the surface of the moon is a little more important that just saying "it's probably going to be fine.".

[ichabod801]

Yeah, the article had some good points, but it was clearly about critical systems.