How do I migrate from imp?

[brettcannon]

@hroncok

However, I still don’t know if this:

1. is actually correct
2. is the one obvious way to do it

Yes and yes (I think).

@vstinner

Please help me to get my proposed importlib.util.load_source() function added to Python 3.12 stdlib

Do note that what you’re proposing and what @hroncok is proposing are different things. What you’re proposing is the pure Python file case where you don’t want a normal search performed (i.e. imp.load_module() for just Python code at any file path). What Miro is proposing is search + load (i.e. imp.find_module() + imp.load_module() following import semantics, albeit is specified directories).

And this is why I have not tossed in a ton of helper functions into importlib.util; everyone wants something slightly different. Luckily the abstractions and composability of importlib should be enough that most things are about 4 lines.

@vstinner

You can explain your use case in the PR to convince Brett

And Thomas as I still think it’s a new feature and thus would need RM approval.

@kknechtel

It shouldn’t be complicated to say “here is a path to a .py file; please give me the corresponding module object” (with or without putting it into sys.modules).

It’s not, hence why it’s documented in 4 lines of code .

importlib — The implementation of import

@Rosuav

Should be easy enough as a simple function in importlib

People say that, but then everyone wants something slightly different in the various scenarios. For instance, @kknechtel wanted the option to not insert the module into sys.modules. No one has brought up packages versus modules. And this is all over what can be accomplished in 4 lines (yes, I realize not everyone wants to read the docs to understand finders versus loaders, but it’s still at least not a ton of code).

I also want to point out the imp module has been pending deprecation for 10 years and a direct deprecation for 8 years. There hasn’t been a flood of asks until now when people are panicking.

Now, I am totally happy to consider adding things to importlib.util based on what @hroncok and friends discover in their journey of dealing with folks ignoring deprecation warnings for 8 years. But I do want to try and ground it in real-world needs that are common and not on one-off scenarios that can be solved in 4 lines of code, else we are going to end up a bunch of little functions that don’t get enough usage to warrant me having to maintain them forever (because, let’s be honest, we all know I’m going to be asked to maintain them ).