My admittedly incomplete understanding is that this is an escalated discouragement (used to be a precompilation failure and warning) of type-pirating method replacement because this otherwise allows package loading order to determine which method exists. I linked a clear example, but in short, if both packages B and C overwrite a method in a dependency A, using B, C
exposes a different method from using C, B
. You probably only have the 1 package overwriting a method in the dependency, but someone else might make another, and whoever tries to use both your packages will encounter this problem. This kind of type piracy was always a problem, but it’s even more so now that there is much more precompilation to waste.
Given an error instead of a warning, you can’t leave it alone at failed precompilation anymore. Method replacement in __init__
cannot be precompiled and thus dodges the issue, though it still invalidates methods in the dependency. More drastically, you could opt the entire module out of precompilation with __precompile__(false)
, which the upcoming precompiler fix seems to do for you. Errors that point out more things more specifically could be nice for all the things we can’t feasibly precompile like load-time constants, memory address-dependent values, or referencing other modules’ global state.