Implement PEP 302 optional get_code loader method

[P403n1x87]

We implement the optional get_code loader method. This increases compatibility with other tools/libraries that need to manipulate the code object of a module before it is executed.

[RonnyPfannschmidt]

i see no reason add this random state - the spec is used to get it anyway

[P403n1x87]

This is needed inside get_code as the argument is the fullname of the module rather than the file path. The same thing is done in the FileLoader from the stdlib https://github.com/python/cpython/blob/2433cc79d79d9c1db8e53d4b9bde26e9a47fb0b9/Lib/importlib/_bootstrap_external.py#L924

[RonnyPfannschmidt]

as the object you changed is not just a loader, but also a MetaPathFinder - it would be necessary to split those objects before the state would be permissible as there would be more than one loader instance with different values

[RonnyPfannschmidt]

cpython has those split up as well - see https://github.com/python/cpython/blob/2433cc79d79d9c1db8e53d4b9bde26e9a47fb0b9/Lib/importlib/_bootstrap_external.py#L1267 for reference

[P403n1x87]

it would be necessary to split those objects before the state would be permissible

I could try to create a full name -> origin mapping on the finder instead, to keep the changes small. How does that sound?

[RonnyPfannschmidt]

unless there is a compelling example where this helps im opposed to the change as it introduces fragile state just to introduce one optional old method

[P403n1x87]

unless there is a compelling example where this helps

Here's one concrete example where we have to work around this DataDog/dd-trace-py#12812

optional old method

I'm not sure I understand the meaning of "old" here 🤔 . I think implementing this method is good courtesy to other libraries that might have the need to interact with the code object. Here pytest is making the assumption that it is the only tool to manipulate code object, and therefore feels no need to implement get_code.

[RonnyPfannschmidt]

please understand that composing a PR about a import behavior changes in the github ux that adds state that may be fragile in multiple steps wit errors and without providing background for the need creates a bias

[RonnyPfannschmidt]

this seems good for now - i haven't yet taken a look if we have a place in the test-suite that would allow for a reasonably easy to write test for this