The same applies to pyexpat.model. It seems like pyexpat is the only builtin module which has submodules (errors, model). Normally, as I understand it, the module gets imported given a spec and the import machinery ensures that this spec ends up in the __spec__ attribute of the module. But in this case only pyexpat gets imported by importlib. The submodules are added when initializing the module. Also, importlib's BuiltinImporter assumes that a builtin module is never a package. Is this reasonable in this case?
The BuiltinImporter's assumption is reasonable because there are no built-ins that are packages. :) In pyexpat's case it's an extension module, not a built-in. As for the expat issue, a patch that backfills the missing info would probably be reviewed.
You're of course right that pyexpat is an extension module and not a builtin module. I was confused because on PyPy it's a builtin module. But the same question applies for ExtensionFileLoader.is_package(). It returns False in the case of pyexpat. This function looks a bit strange to me anyway. It assumes the definition of what a package is for pure Python modules and applies it to extension modules.
ExtensionFileLoader.is_package() is accurate because it's not typical for an extension module to inject its own submodules like pyexpat is. Usually people who use an extension module in a package use it just for a submodule and not even as an __init__. IOW there's a long history of built-ins and extensions not being in packages that people bump up against that no one has taken the time to try and straighten out due to it not being an issue on a regular basis.
Right, there's a longstanding RFE to allow builtin packages and submodules: https://bugs.python.org/issue1644818 At the moment, modules like pyexpat are more like the os module than they are packages: they eagerly set other modules as attributes at import time (akin to os.path), rather than defining an actual package with submodules that can be optionally loaded via the import system. Given the import system changes in recent 3.x releases, I'd expect it to be feasible (but not necessarily easy) to come up with a viable specification and implementation for builtin and extension packages that work similarly to traditional packages (perhaps based on the handling of frozen packages).
