"Goto" statement in Python

Mikhail V mikhailwas at gmail.com
Sun Apr 16 03:21:12 EDT 2017

On 14 April 2017 at 03:44, Steve D'Aprano <steve+python at pearwood.info> 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
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

|        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

         clean_up something
         clean_up something


or a classic:

x, y = 0
xx, yy = 300

||       x = x + 1
||       if (x+y) > 100 : goto .x
||       if (x>xx) : goto .1
|        y = y + 1
|        if (x>xx) : goto .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.


More information about the Python-list mailing list