This is really, really useful for doing language-to-language translation. Without the ability to arbitrarily branch from basic block to basic block, it's possible for the basic block graph produced by a program in one language to be simply inexpressible in your target language. You end up having to fake it with a while loop and switch statement, which has horrible performance implications.

(Emscripten has some exotic algorithms to try and express the source program's basic block graph using the target language's structured programming constructs. This is vitally important to make goto-less Javascript perform well, but it can't work in all cases, and some C functions will force Emscripten to fall back to loop-and-switch. And, of course, these functions are typically the ones which have been carefully hand-optimised for speed...)

I'm sure neither should be used in a production project.

[1]: https://github.com/snoack/python-goto/blob/master/goto.py

Sorry, I had to.

Some examples you'd expect to work that will crash the interpreter:

  @with_goto
  def fun1():
   while True:
    for x in [1]:
     goto .next
    label .next
  
  @with_goto
  def fun2():
   goto .next
   for x in [1]:
    label .next
  
  @with_goto
  def fun3():
   while True:
    try:
     goto .next
    finally:
     print('skipped')
    label .next

And presented at KiwiPycon 2014: https://www.youtube.com/watch?v=DdU8I09BGsU

As an example, I've got a PR open right now that lets you do things like:

    @mutable_locals
    def f():
        out = []
        x = 1
        out.append(x)
        locals().update({'x': 2, 'y': 3})
        out.append(x)
        out.append(y)
        return out

    assert f() == [1, 2, 3]

Neat hack, though.

[1] http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T...

The idea that it needs optimizing, no doubt because someone's using it in a hot code, is hilarious. That's either the best satire or the worst truth I've heard all day.

I know this is a problem for at least the Byteplay module.

  (loop
    (tagbody
      (loop for x in '(1 2 3)
            do (go next))
    next
      (print 'out)))

How it works is that tagbody contains a bunch of labels mixed with forms. The tagbody establishes an exit point for GO expressions used in these forms. When a (go label) occurs, it works by abandoning the current sub-form being evaluated, and initiating a control transfer to the exit point, which then transfers control to the appropriate label.

The upshot is that whatever form is interrupted will cleanly unwind, as necessary:

  (tagbody
    (unwind-protect (progn 
                      (go out)
                      (progn 'never-printed))
      (print 'bye-bye))
   out)

  (tagbody
     (go impossible)
     (let ((x 42))
       impossible x))

Thus, compilers only have to reason about GO within specific constructs, and rely on those GO's to only be performing abandonment followed by a simple lateral move.

Jumps out of loops and other blocks work now. However, there are some limitations:

1. As I only have 4 bytes left to inject POP_BLOCK instructions, you can't exit more than 4 blocks with a goto. But this is handled and results into a SyntaxError rather than crashing Python.

2. Jumps into loops still doesn't work. However, it's handled now, and causes a SyntaxError as well.

3. When jumping out of a try- or with-block the finalizer is skipped.