On 28 December 2015 at 11:00, Erik
On 28/12/15 00:41, Guido van Rossum wrote:
Can you show the diffs you have so far? Somebody's got to look at your code.
Sounds like it's not a well-known symptom then.
The symptom is well known (at least to folks that have worked on the compiler and eval loop since the switch to importlib as the import system implementation), but the circumstances where it can arise are *very* limited. Specifically, being unable to load the import system while working on CPython is usually a sign that: 1. The interpreter's bytecode generation is inconsistent with the implementation of the eval loop 2. importlib._bootstrap includes code that triggers the inconsistent bytecode processing path 3. Freezing importlib._bootstrap to create _frozen_importlib thus produces a frozen module that won't load with the given eval loop implementation If you're not hacking on bytecode generation or the eval loop (1), or your changes to the bytecode generator and/or eval loop don't impact the code in importlib._bootstrap (2), then you won't see this kind of bug (3).
I agree, but that Somebody should be me (initially, at least) - I don't want to waste other people's time if I made a silly mistake.
In this particular case, it's hard to help debug the error without being able to see both the new code generation changes and the corresponding eval loop changes. It's also the case that to rule out the bootstrapping cycle as a potential source of problems, you can try the following manual dance: 1. Revert to a clean checkout and rebuild 2. Apply the eval loop changes, and rebuild 3. Apply the code generation changes, and rebuild That generally *shouldn't* be necessary (it's why there's a separate build step to freeze the import system), but it can be a useful exercise to help figure out the source of the "unknown opcode" problem. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia