[issue34534] importlib.resources does not work with packages that have no __init__.py
Girts Folkmanis
report at bugs.python.org
Tue Aug 28 15:00:56 EDT 2018
New submission from Girts Folkmanis <opensource at girts.me>:
importlib.resources does not seem to work with packages that don't have __init__.py present. Since 3.3+ generally there is no need to create empty __init__.py, as directories are automatically treated as packages even without the file present. So my expectation would be that importlib.resources would follow the same suit.
Repro, where I expect that both "mod1" and "mod2" would return the files when contents() is called:
$ find .
.
./mod2
./mod2/data.txt
./test.py
./mod1
./mod1/__init__.py
./mod1/data.txt
$ cat test.py
import importlib.resources
print('mod1:', list(importlib.resources.contents('mod1')))
print('mod2:', list(importlib.resources.contents('mod2')))
$ python3.7 test.py
mod1: ['__init__.py', '__pycache__', 'data.txt']
mod2: [] # <---- here I would expect to see files too
Looking at the source of Lib/importlib/resources.py, there is the following code in contents():
[..]
# Is the package a namespace package? By definition, namespace packages
# cannot have resources. We could use _check_location() and catch the
# exception, but that's extra work, so just inline the check.
elif package.__spec__.origin is None or not package.__spec__.has_location:
return ()
[..]
This is the branch that is taken - but it's not necessarily a namespace package here, at least to my understanding. Is there a way to make the code here distinguish between namespace packages and implicit non-namespace packages here, and allow contents() (and other functions) to work?
----------
components: Library (Lib)
messages: 324275
nosy: girtsf
priority: normal
severity: normal
status: open
title: importlib.resources does not work with packages that have no __init__.py
versions: Python 3.7
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34534>
_______________________________________
More information about the Python-bugs-list
mailing list