Thanks Eric! I've left some detailed comments on the PR, with the main one being to include the "expected" table directly in the test case so it doesn't require any changes to importlib itself.

For Serhiy - thanks for the explanation of the potential security impact of the original bug, as well as the additional patch that resolves that aspect even for the invalid bytecode.

As for as the complexity of the test case itself goes, the main cases we're interested in here are how it fails:

- when an RM goes to make a candidate release, they may forget to record the now expected magic number for that release series and get prompted by the failing test case. We'd like them to be able to just copy the magic number from _bootstrap_external.py directly into the table of expected magic numbers

- when someone attempts to bump the magic number in a maintenance release, we want the warning that that's a higher impact change than it may first appear (one we know how to deal with now, but still something we'd prefer to avoid if we possibly can)

So I think it makes sense to have a relatively verbose test case, even though the core of it is a really simple check of a single value.