Import machinery for extracting non-modules from modules (not using import-from)

Adam Preble adam.preble at gmail.com
Mon May 4 02:00:22 EDT 2020


The (rightful) obsession with modules in PEP-451 and the import machinery hit me with a gotcha when I was trying to implement importing .NET stuff that mimicked IronPython and Python.NET in my interpreter project.

The meat of the question:
Is it important that the spec loader actually return a module? Can it just return... stuff? I know a from X import Y is the normal means for this, but if the loader knows better, can it just do it?

A normal process is something like:
import X

A bunch of finders line up to see if they know anything about X. If they don't, they return None. Assume it's found. That finder will return a module spec for how to load it.

A little later, that spec is instructed to load the module.

If X wasn't a module, you can expect to see something like:
ModuleNotFoundError: No module named 'X'; 'X' is not a package

...you were supposed to do 'from something import X'. I'm actually trying to figure out if there's a way with normal Python modules where I can even be in a situation to just blandly trying to import X without a package in front of it.

With IronPython--and I'm pretty sure Python.NET, there are situations where you CAN do this. The paths for .NET 'packages' are the .NET namespaces (a slightly different usage of the term). Say I want the machine name. It would be typical to get that with System.Environment.MachineName. MachineName is a static field in Environment. System.Environment is a namespace in mscorlib (in classic .NET framework).

The .NET namespace can be null. In that case it's just in the root namespace or something. Let's say I have a .dll I've made known to IronPython or Python.NET using its clr.AddReference, and I want to toy with some class defined without a namespace called "Crazy." This is totally fine:
import Crazy

I really can't follow what either one is doing here, and I don't know how well they're even latching on the PEP-451. So there's the main question: is it important that the spec loader actually return a module? Can it just return... stuff? I know a from X import Y is the normal means for this, but if the loader knows better, can it just do it?


More information about the Python-list mailing list