[issue29830] pyexpat.errors doesn't have __spec__ and __loader__ set

[Nick Coghlan]

Nick Coghlan added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29830] pyexpat.errors doesn't have __spec__ and __loader__ set

[Brett Cannon]

Brett Cannon added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29830] pyexpat.errors doesn't have __spec__ and __loader__ set

[Manuel Jacob]

Manuel Jacob added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29830] pyexpat.errors doesn't have __spec__ and __loader__ set

[Brett Cannon]

Brett Cannon added the comment:

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.

--
nosy: +brett.cannon, eric.snow, ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29830] pyexpat.errors doesn't have __spec__ and __loader__ set

[Manuel Jacob]

New submission from Manuel Jacob:

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?

--
messages: 289737
nosy: mjacob
priority: normal
severity: normal
status: open
title: pyexpat.errors doesn't have __spec__ and __loader__ set

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com