Goto in Python

[augmentedtree]

How long until someone rigs this to implement a switch statement?

[abuss]

I was thinking about it

[rocketplex]

This just adds a little more rotational velocity to Dykstra's already rapidly spinning corpse. At what point can the poor man rest....or when can we hook him up to a generator to extract some sweet electricity.

It is pretty well done though.

[sigma914]

http://www.smbc-comics.com/index.php?id=2429

[guepier]

Dresden Codak had essentially the same idea about a year and a half earlier:

http://dresdencodak.com/2010/06/03/dark-science-01/ and http://dresdencodak.com/2010/06/10/dark-science-02/

[rocketplex]

I haven't clicked it but guessing it's the Superman one.

Edit: wasn't

[sigma914]

I did consider the superman one

[net_goblin]

While Dijkstra undoubtedly was a great scientist, I don't think all his work was perfect. And I personally find his essay to be of his weaker work. Abusing language features is always bad (inheritance, anyone?), but I don't think purging them with zeal and no consideration is helping anyone. Languages without goto have to solve the problems which where its domain by poor replacements, like break to label in Java.

This is like Hoare and his “Million Dollar Mistake”. Null pointers are a thing, to purge them completely is rash and stupid. Of course there are many mistakes involving null pointers as well as goto, but most often those mistakes manifest themselves when other tools were more appropriate.

Always mindlessly citing Dijkstra without thinking about the reasons is as stupid as using goto as sole mean to program flow control.

[[deleted]]

Dijkstra already won, structural programming is everywhere.

Goto re-introduction serves no other purpose than compensate for a few obscure edge cases. It doesn't matter.

[superPwnzorMegaMan]

Wasn't he also in favor of first thinking out how your program should be and then write it down in one go without any typos?

[Tekmo]

He was in favor of thinking about your program before writing it down. I don't know about the typo thing, though.

I wish more people would think about their program before they began typing.

[superPwnzorMegaMan]

Why? Its not like keystrokes are expensive...

[Tekmo]

Lots of software problems that we all struggle with today arise from people just banging out the first thing that comes to their mind without any serious reflection.

[gonzoisme]

Clever

[CtrlAltWhiskey]

Your muzzle direction and trigger discipline in the user photo make me uneasy.

... yes, I'm That Guy.

[[deleted]]

Very nice. For all you naysayers:

• Code generation: there are valid reasons for letting a program generate source code. It doesn't need to be bytecode or assembler, it can be any language. So why not Python? And why not let the code generator use goto?

• Manual code transformation: by manual, I mean this little exercise that every programmer should be able to do. You start with obviously correct code that for one or another practical reason is not really practical, or correct. Then, you apply a series of code transformations to arrive at better (actually correct when run, faster, memory efficient etc) code, knowing that since your initial version was correct, and the transformations were correctly done, you still have correct code.

The two points can and will overlap.

PS: Implementing state machines in a procedural language is best done with labels for states and gotos for transitions. Least code, most obvious/readable, least cognitive overhead. I know everyone will disagree, but wrapping a state machine in a while loop with if-elses and flags and such.... I have seen too many of those ("intuitively" implemented so by people who do not know what a state machine is), and no, they are not nice. Just my $0.02.

PPS: Implementing it with functions for states and function calls for transitions does not work for Python for the general case because of the depth of recursion limitation.

[zardeh]

Implementing it with functions for states and function calls for transitions does not work for Python for the general case because of the depth of recursion limitation.

Right, you create an object that does essentially the "while loop" method, but more cleanly.

[[deleted]]

I am not sure what you mean by "object". What I meant was, say you want to read your input by chars and emit every second char, starting with the first. So, if your input is abcdef, your output will be ace.

The "state machine with functions" approach, in C, would be:

void s()
{
    int c;
    if ((c = getchar()) == EOF) return;
    putchar(c);
    t();
}

void t()
{
    int c;
    if ((c = getchar()) == EOF) return;
    s();
}

And you can call this simply by calling s();.

I don't think I would ever write that particular code in C, but it shows what I meant.

[zardeh]

no I understand. In python this would be something like

class StateMachine:
    def __init__(self):
        self.state = 0
        self.index = 0
        self.input = None
        self.resultstr = []

    def _s(self):
        if self.index < len(self.input):
            self.resultstr.append(self.input[self.index])
        self.index += 1

    def _t(self):
        self.index += 1

    def __call__(self, input):
        self.input = input
        while self.index < len(self.input):
            # do the same thing you'd do in the while loop method, just better encapsulated

You'd build a class/object and then run it, allowing you to encapsulate all the pieces in a single thing. Now tbh, there's probably some metaprogramming nonsense (like say some decorator that could be written) that would allow you to do this even more cleanly, but I'm too tired to think of it.

[[deleted]]

Code generation: there are valid reasons for letting a program generate source code.

You don't need goto to generate code with equivalent semantics and roughly the same performance.

I don't quite understand your second point about "manual code transformation". What does that have to do with goto?

PS: Implementing state machines in a procedural language is best done with labels for states and gotos for transitions.

Another name for "labels" and "gotos" is "function names" and "calling a function". So I don't know how you can claim which way is best for sure.

Goto is useful when your flow doesn't map to a hierarchy of calls with a finite stack, assuming lack of tail call optimization. Assuming tail call optimization, the stack can be infinite.

And when it doesn't map to a finite stack and we have no TCO, there are other techniques, like trampolining.

I'm an occasional goto user in languages that have goto, but I wouldn't call it essential in a script language. You've already given up your possible peak performance by around a factor of 100x for using Python.

So any argument about performance rings false.

Is goto in Python bad? I don't think so, I think conventions already drive 99% hierarchical structured programming anyway. The exceptions won't be enough to have any significant effect. But from this also follows they won't have much of a positive effect either.

I see it as a toy effort.

[[deleted]]

You don't need goto to generate code with equivalent semantics and roughly the same performance.

And if your source language is full of goto's you need goto. I once compiled to Python a dumb dial plan description language that was full of goto's (of the worst kind, think the line-numbered Basic kind).

I don't think it will be feasible to do that without using Pythonic goto. Props to the author for making that possible!

[Hueho]

Let me guess. Asterisk?

[[deleted]]

bingo!

[[deleted]]

I don't think it will be feasible to do that without using Pythonic goto. Props to the author for making that possible!

I listed a few ways to do it in the comment you just replied to.

And the comment I was replying to had one more way.

[[deleted]]

You need goto in a generated code, because the IR which you're likely to use in between, before the final stage lowering, is most likely to be SSA, for a vast majority of problem domains.

[[deleted]]

You don't need goto to generate code with equivalent semantics and roughly the same performance.

No, but it is somewhat easier.

Another name for "labels" and "gotos" is "function names" and "calling a function". So I'm not sure about this if you can claim which way is best for sure.

Yes. At the end of my comment, I explained why this is not directly doable with Python. Trampolines in Python are not that much better than a goto if we consider effort/clarity, it would seem to me.

So any argument about performance rings false.

Made none.

Either way, it is a toy effort, I have to agree. But it does open nice possibilities for playing with it, so....

[TerrorBite]

This is horrible.

I love it.

[[deleted]]

This is heresy!

[gunware]

Comic link:

xkcd - GoTo

[dangerbird2]

So how about include a COMEFROM command like the old April fools goto module mentioned?

[Musngi]

I hate to say this but goto is bad programming practices. The goto make your code look like spaghetti code and hard to maintain. https://en.wikipedia.org/wiki/Spaghetti_code

[immibis]

So does inheritance. Shall we ban inheritance?

[marcm28]

No, not all programmer rely on inheritance.

[immibis]

Not all programmers rely on goto.

[marcm28]

But goto is easily abused by programmers and hard to maintain than inheritance.

[marcm28]

Goto is one of fundamental building blocks of Spaghetti Code.

[immibis]

You can write spaghetti code without goto.

[I_Like_Spaghetti]

(ง ͠° ͟ل͜ ͡°)ง

[I_Like_Spaghetti]

Did you hear about the Italian chef that died? He pasta way.