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.

source_to_code() seems like a good fit on InspectLoader to me.  Is there
something in particular that motivated the idea of moving it up to Loader?

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 something
  with open('file.py') as file:
    module = loader.source_to_module(file.read(), location='file.py')

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.

New changeset 9bd844792b32 by Brett Cannon in branch 'default':
Issue #21156: importlib.abc.InspectLoader.source_to_code() is now a
http://hg.python.org/cpython/rev/9bd844792b32

I decided to make it a static method instead of relocating it.