Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader

[brettcannon]

BPO	21156
Nosy	@brettcannon, @carljm, @ericsnowcurrently

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/brettcannon'
closed_at = <Date 2014-05-09.16:29:21.556>
created_at = <Date 2014-04-04.17:59:20.194>
labels = ['type-feature', 'library']
title = 'Consider moving importlib.abc.InspectLoader.source_to_code() to importlib.abc.Loader'
updated_at = <Date 2019-05-28.20:32:36.770>
user = 'https://github.com/brettcannon'

bugs.python.org fields:

activity = <Date 2019-05-28.20:32:36.770>
actor = 'brett.cannon'
assignee = 'brett.cannon'
closed = True
closed_date = <Date 2014-05-09.16:29:21.556>
closer = 'brett.cannon'
components = ['Library (Lib)']
creation = <Date 2014-04-04.17:59:20.194>
creator = 'brett.cannon'
dependencies = []
files = []
hgrepos = []
issue_num = 21156
keywords = []
message_count = 8.0
messages = ['215544', '215628', '215631', '215637', '218174', '218175', '343735', '343817']
nosy_count = 4.0
nosy_names = ['brett.cannon', 'carljm', 'python-dev', 'eric.snow']
pr_nums = []
priority = 'low'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue21156'
versions = ['Python 3.5']

[brettcannon]

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.

[ericsnowcurrently]

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?

[brettcannon]

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')

[ericsnowcurrently]

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.

[python-dev]

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

[brettcannon]

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

[carljm]

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.

[brettcannon]

@carl Feel free to open new issues for whatever you need. :)