Thanks, very much appreciated! But reviewing this huge PR is difficult. Let's land #21 separately, and if you don't mind can you move the other changes that are unrelated of supporting Python 3.8 to separate pull requests as well?

Also can you update tox.ini, .travis.yml and README.md in order to cover Python 3.8?

I've split this PR into py38 and non-py38. (This is the non-py38 PR and should be merged AFTER the py38 PR)

Splitting the PR further would be too much work, though, and it contains mostly related fixes (+ one unrelated minor change that should hopefully be easy to review together with the rest - just look at lines containing _patched_code_cache)

Let me know if you're unsure about why something's been added or changed, I'll gladly explain.

I didn't do a full review yet (as this pull request is difficult to review until rebased/merged against master) but I already have a couple remarks:

1. I'm not a fan of the caching. It seems like a premature optimization and a potential memory leak. But I also fail to see a common scenario where the same code is passed through the goto decorator more than once.
2. Specifically detecting __pypy__ seems wrong to me. I rather stick to feature detection (e.g. compile some code, and inspect the resulting bytecode, like I did in order to detect Python 3.6+ wordcode, see the _Bytecode class and how its properties are initialized).

I've updated the changes per flake8 & your notes in the other PR.

To respond to your questions above:

1. The common scenario that this handles is as follows:

def outer_func():
        @with_goto
        def inner_func():
            <do something func with gotos>
        return inner_func

Since the decorator runs every time outer_func is called, we would needlessly patch the function's bytecode every time (E.g. imagine outer_func is called in a heavy loop).
This results not only in needless speed loss but also in needless creation of duplicate code objects.
This is why caching is required and is not a premature optimization.
As for a memory leak - that's what using a weak-keyed dictionary should resolve. (Supported in py2.7+). Plus, code objects usually have infinite scope, so it's not a real concern even in py2.6 (compared with the alternative).

2. Hmm, that could work - I'll give it a try.

Additional notes:

3. I added two "noqa"s - one for the pypy import (will probably be removed per (2)) and one for a test checking the "except:" case (I moved most tests to check the "except Exception:" case, but keeping one good test for the "except:" case is important too.

4. Due to changing the "except" to "except Exception" in the testcases, I ended up finding a new issue. To resolve it, I made some additional code changes, including "backporting" a relatively major change from the next PR - code no longer relies on POP_BLOCK but instead looks at the jump argument supplied in the SETUP_* opcodes, which seems more reliable in several cases.
   (To be clear, the "backported" changes are relevant to this PR - the fixing of various crashes/etc in existing supported python-goto functionality)

5. Let me know if you want me to make the following improvement to the code:
   Use namedtuple instead of the brittle ,,x=y and y[0] approaches. (Supported in py26+ so should be good)

EDIT: I'll also do a refactor of _find_labels_and_gotos to make it use a class for the block_stack management, as it's currently quite brittle (especially due to the lack of python3.x's nonlocal)
EDIT EDIT: Done.

About (2), while it's not possible to (normally?) detect this at runtime (since the generated opcodes are the same - their semantic is different), I realize I could largely remove the feature check altogether and always write the END_FINALLY when exiting finally/with blocks (previously - was only written for pypy).

In fact, one could well say that not calling END_FINALLY in such cases is a bug, just one that non-pypy pythons don't care about (of course, one could say the same about adding goto to python in general, but let's not go there :P)

Let me know if you'd rather have the pypy feature check over writing 2 extra opcodes (BEGIN_FINALLY/equivalent & END_FINALLY) in all relevant cases. The extra 2 opcodes shouldn't be a problem now that we can write how much we want.

Also, I went ahead a bit further and made some changes to fully handle the _BYTECODE.has_begin_finally flag by translating SETUP_FINALLY to SETUP_EXECPT once detected as well. This allowed me to remove the pypy feature check entirely (as opposed to under the !has_begin_finally feature check).
It's not strictly required, but fits better with the "you should call END_FINALLY after finally/with blocks" narrative and will be helpful if we ever want to add other changes that rely on SETUP_EXCEPT.

This PR is now ready from my perspective. Let me know if you want any changes.