python-goto

It indeed does not work. I was curious, and found this hilarious article "confirming" its existence: https://www.edureka.co/blog/goto-statement-in-python/ - it's complete nonsense and appears to have been written by ChatGPT. The feature has been implemented a few times as a joke (more or less), e.g. https://github.com/snoack/python-goto/, but that one at least hasn't been updated for 5 years.

Goto is control flow. You can’t do control flow with function calls in the sorts of languages we’re talking about, so goto has to be built into the language, typically as a statement. (In some of these languages you can do awful hacks like using hooks intended for debuggers <https://entrian.com/goto/> or rewriting bytecode <https://github.com/snoack/python-goto>, and frankly what Svelte does is quite similar, just implemented as a compilation step rather than at runtime.)

Fixed: https://github.com/snoack/python-goto/commit/a46dbe57e9cfa4f... 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.

I did run the example from the README, with "%timeit range(0, 1000)" in ipython: 10000 loops, best of 3: 72.9 µs per loop @ CPython 2.7.10 with NOP 10000 loops, best of 3: 77.2 µs per loop @ CPython 2.7.10 with JUMP_FORWARD 10000 loops, best of 3: 106 µs per loop @ CPython 3.5.0 with NOP 10000 loops, best of 3: 106 µs per loop @ CPython 3.5.0 with JUMP_FORWARD 100000 loops, best of 3: 8.6 µs per loop @ PyPy 2.4.0 with NOP 100000 loops, best of 3: 8.7 µs per loop @ PyPy 2.4.0 with JUMP_FORWARD To my surprise, in fact, JUMP_FORWARD isn't any faster than 7 NOPs. In Python 2.7, JUMP_FORWARD is even slower. So reverted: https://github.com/snoack/python-goto/commit/d19d244a9e5efdf... Thanks for the pointer!

> I wonder if there's a way to remove the extra nops? Yes, technically it would be possible to remove the code instead injecting NOPs. But then I'd have to adjust the jump targets. However, I don't think these NOPs are too bad. Note that goto jumps directly after the NOP ramp of the label, and the NOPs of the goto itself are never reached. The only scenario where NOPs are actually seen by the interpreter is when the natural code path visits a label. EDIT: Instead re-assembling the bytecode and adjusting jumps, I went to use JUMP_FORWARD(3) instead 7 NOPs now. Note that there are still 4 NOPs left to fill the gap, these however are never executed as they are skipped by the preceding jump instruction. https://github.com/snoack/python-goto/commit/2b0f5e5069cbb88...

The technique used to implement this is rather interesting, and the implementation itself[1] is very understandable. I'm sure neither should be used in a production project. [1]: https://github.com/snoack/python-goto/blob/master/goto.py