On Mon, May 16, 2022 at 7:38 AM Greg Werbin <outth...@me.gregwerbin.com> wrote:
> Non-"binary" resources are already in widespread use, I didn't write the docs -- but a text file is, indeed a binary blob -- it only becomes text when it is read and decoded, so there is no distinction at this level. I *think* the idea behind that is that a resource is not necessarily a file on disk -- which is why it's not called a file. It is a blob of bytes (i.e. binary) that is stored somehow and can be retrieved somehow. In practice, I imagine most resources are indeed files, or at least start that way before they are packed into a zip archive or something. > so perhaps that requirement shouldn't be in the docs at all. In practice, > a resource is "any data file other than a Python source file." > See above -- a resource may not be a file. > Moreover, I see no reason why a resource name in general shouldn't be > allowed to contain a "/" character! I agree here -- this may very well be the solution -- have any of you tested it? I have not -- it may well be possible right now. Is there any code checking and rejecting resource names with a slash in them? BTW -- can someone point to a good example of resources in action -- I find it a bit challenging to work only fjrom documentation -- I really like concrete examples. Another note: IIUC, the entire point of the "resource" abstraction is because they may not be files on disk (at least at run time). I, and many others have included data file in packages in a very simple way: 1) Add the file to the directory where you want it. 2) Make sure your package builder (e.g. setuptools) copies the file into the package on installation 3) Find the file at run time with a relative path to the __fille_ attribute in a parent package. This is simple, straightforward and works great -- as long as your package is only used with a conventional install (set zipsafe to False for setuptools. But it breaks when the package is installed some other way -- as a zip file, maybe by PyInstaller, or who knows what? I'm pretty sure THAT is the problem that importlib resources is trying to solve in an abstract way. From: https://importlib-resources.readthedocs.io/en/latest/using.html """ What exactly do we mean by “a resource”? It’s easiest to think about the metaphor of files and directories on the file system, though it’s important to keep in mind that this is just a metaphor. Resources and packages *do not* have to exist as physical files and directories on the file system. """ Note from that document, there is this example: from importlib_resources import files # Reads contents with UTF-8 encoding and returns str. eml = files('email.tests.data').joinpath('message.eml').read_text() In that case, there is a directory, `data`, that has a __init__.py file in it, making it a package. Note that you still need to use joinpath to make the final path to your resource -- what happens if you add a nested path there? eml = files('email.tests.data').joinpath('subdir/message.eml').read_text() It may "just work" :-) Keep in mind that the other point of importlib.resources is to leverage the import system -- the import system defines a package as a dir with a __init__ -- and it already knows how to find files (or abstactions of files) in a package. There is no such thing as a "resource directory" as distinct from a package -- and I don't think adding that complication is worth saving the effort of adding a __init__.py to a dir in which you want to store resources. After all, if you want to put modules in a nested dir, you have to add a __init__.py to the dir as well. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/U36W5H346PJFBPVSZAGV4JZW6U5HFBMX/ Code of Conduct: http://python.org/psf/codeofconduct/
