importlib.abc.InspectLoader.source_to_code exists on InspectLoader because InspectLoader.get_code() uses it. But there is technically no reason to leave it there and not simply move it up to importlib.abc.Loader(). There is also no reason to not make it a staticmethod so that one can use it without worrying about abstractmethod overrides.
The inspiration was that I realized there was no technical reason to have it on InspectLoader. Past that there was my thinking of trying to come up with a source_to_module() method on importlib.abc.Loader which would do the right thing with create_module() and init_module_attrs() such that replicating imp.load_module() would be something like::
loader=importlib.machinery.SourceLoader# or somethingwithopen('file.py') asfile:
Now that I've thought about it a little more, I'm more open to the idea. Source is definitely a universal concept in Python, as is code. So source_to_code() makes some sense on a most-base type like Loader. On the other hand, source isn't necessarily associated with all loaders.
I guess my initial gut reaction was that it seemed out of place API-wise. On InspectLoader it's presence is tied to get_code(), so it makes more sense.
Making source_to_code a staticmethod on the InspectLoader abc but not in the importlib.machinery implementation causes awkwardness for anyone trying to inherit SourceFileLoader and override source_to_code in typechecked code, since typeshed assumes that SourceFileLoader actually implements the importlib.abc.FileLoader interface.
Given the ABC registration, it seems that importlib.machinery.SourceFileLoader should in fact implement the importlib.abc.FileLoader interface.
Should we make SourceFileLoader.source_to_code a staticmethod also? If so, I can file a separate bug for that.