Provide a read() function?
The design doc says:
That's only 2 lines which everyone knows how to write (the
def
and docstring equate to the same number of lines as the body of the function). The only real reason to support aread()
function is potential performance benefits for loaders reading from e.g. a database.
It's possible we can implement a more efficient reader layer depending on the backend. E.g. by calling ZipFile.read()
directly? The trick there is that importlib.resources
would have to expose things like that method's pwd
argument to truly be compatible (is it worth providing a read()
operation that wouldn't support encrypted zip files?) I'm not sure how you'd handle that.
One other possible convenience for read()
would be to support text files. It's of course easy to wrap binary open()
in something that does the decoding, but now you potentially have a stack of tricky wrappers around the low-level API. We could provide those as convenience, but only if they really are for the majority of use cases. We probably can't meet them all. Still, this would be really useful:
from importlib.resources import read
my_config = read('my.project.configs', 'base.cfg')
where text+UTF-8 would be the default. I think it's going to be very common to want to read text files.