Any plan to continue maintaining this?
FelixFourcolor opened this issue · comments
If you have time, I think this is a great programming joke that deserves to be continued.
Yes. As it happens I plan to fix it next week. Unfortunately the nature of the project means that 'hidden' changes to the python byte code can break it easily. And fulltime work + having long covid means no promises.
Lol. Just ran across this as I was updating https://github.com/BartMassey/hamurabi , which uses it. Timing. Would love to see this uploaded to PyPy once it's working again…
I tried to quickly fix for current Python, but it seems like a big project. A lot has changed in the intervening years, and the undocumentedness (as far as I can tell) of Python bytecodes is a big barrier. @cdjc let me know if you're not going to get to it anytime soon, and I will add it to my long list of todos.
I've got a branch with goto working in 3.11. still needs more testing though.
LOL. Just found an up-to-date doc of Python bytecodes in the dis documentation. This is helpful.
Checked out the 3_11update branch I hadn't seen before. Thanks much! It looks like goto_tests.py still fails for me on Linux Python 3.11.4 : still tries to insert a JUMP_ABSOLUTE that seems to no longer exist as a Python bytecode. I can try to fix it to use relative jumps if you like?
Thanks so much for this! My old BASIC code port may work again someday soon…
Looks like the 3_11update branch is still a work in progress. Let me know if I can help somehow.
Checked out the
3_11updatebranch I hadn't seen before. Thanks much! It looks likegoto_tests.pystill fails for me on Linux Python 3.11.4 : still tries to insert aJUMP_ABSOLUTEthat seems to no longer exist as a Python bytecode. I can try to fix it to use relative jumps if you like?
It's still super-raw in that branch. goto3_11 is the current (and temporary) name of the decorator. I'm actually writing an academic paper for a conference on goto in python at the moment and it's due next week, so I might focus on that for the time being, and add some polish once I've got that paper submitted.
Fair enough. Thanks again!
It seems that the python compiler is now doing some optimisations when compiling, in particular unreachable code detection, and not compiling the "unreachable" code to byte code. Unfortunately, that unreachable code needs to be compiled to bytecode before a goto can "reach" it. Still investigating....
goto now works on 3.11.
The unit tests for 3.11 are now using unittest.
There's not yet any tests for preventing jumping into with blocks, or in to or out from try blocks.
There's a minor issue where the Python byte code compiler now removes "unreachable" code. so:
goto. there
return True # Python removes lines after here as being 'unreachable'
label .there # Python removes this line
return False # Python removes this line
The fix is to add an always-true guard that must be determined at run time to the return. if True: return won't work.
goto. there
if __name__: return True # Lines following return are preserved
label .there
return False
Thanks huge. Sadly, getting JumpTooFar exception on http://github.com/BartMassey/hamurabi/hamurabi.py. Apparently only 8-bit jump offsets are allowed in Python bytecode?