On 29 June 2015 at 07:56, Paul Sokolovsky <[email protected]> wrote: >> If you want to avoid a dependency on pkg_resources, you can use >> pkgutil.get_data (from the stdlib). It doesn't have as many features >> as pkg_resources, but it does the job in straightforward cases. > > Which makes everyone in the audience wonder: how it happens that it's > 2015, Python is at 3.5, but pkgutil.get_data() is in stdlib, while > pkg_resources.resource_stream() isn't? An implementation of > pkgutil.get_data() would be based on pkg_resources.resource_stream(), > or would contain just the same code as the latter, so it could easily > be exposed, and yet it isn't.
In addition to Nick's response, which are the main reasons, there is also a more fundamental issue behind this. The PEP 302 definition of a loader only provides a get_data method, which corresponds directly to pkgutil.get_data. Any additional features provided by pkg_resources are not supported directly by the loader protocol, and so could not be guaranteed to be present for an arbitrary loader. pkg_resources provides the extended features (I believe) by special-casing filesystem and zip loaders, and providing an extension mechanism for other loaders to participate in the functionality, but that extension mechanism is not in the stdlib either. So adding more resource loading features means extending the PEP 302 protocols, etc. That's the work that no-one is currently doing that blocks the process. Having said all this, PEP 302 is pretty old now, and importlib makes all of this *much* easier, so (as long as you're only targeting recent Python versions, which stdlib support would be) it's a lot simpler to do this now than it was when we wrote PEP 302. And of course, in practical terms filesystem and zip loaders are the only significant ones that exist anyway... Paul _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
