In GitLab by @jaraco on May 18, 2018, 11:36
Coming from pkg_resources, I'd previously used __name__ as the initial parameter:
>>> import pkg_resources
>>> import queso.validator.tests.test_options
>>> pkg_resources.resource_stream(queso.validator.tests.test_options.__name__, 'colliding questions.json')
<_io.BufferedReader name='/Users/jaraco/Dropbox/code/yg/G/queso/queso/validator/tests/colliding questions.json'>
But in importlib_resources, this approach doesn't work.
>>> importlib_resources.read_binary(queso.validator.tests.test_options.__name__, 'colliding questions.json')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/jaraco/Dropbox/code/yg/G/queso/.tox/py36/lib/python3.6/site-packages/importlib_resources/_py3.py", line 142, in read_binary
package = _get_package(package)
File "/Users/jaraco/Dropbox/code/yg/G/queso/.tox/py36/lib/python3.6/site-packages/importlib_resources/_py3.py", line 40, in _get_package
raise TypeError('{!r} is not a package'.format(package))
TypeError: 'queso.validator.tests.test_options' is not a package
In other words, importlib_resources seems to be more stringent about the input, requiring the parameter to be a package and not simply a module.
Is this limitation intentional? If so, the migration docs should include a note about this incompatibility.
In GitLab by @jaraco on May 18, 2018, 11:36
Coming from pkg_resources, I'd previously used
__name__as the initial parameter:But in importlib_resources, this approach doesn't work.
In other words, importlib_resources seems to be more stringent about the input, requiring the parameter to be a package and not simply a module.
Is this limitation intentional? If so, the migration docs should include a note about this incompatibility.