I honestly wasn't aware that this was added in 3.7 -- I always thought handling resources was up to setuptools or hand-written code. So it's nice to see that it's there in the stdlib. And while I haven't actually used this feature, I have read through the docs and have a few comments.
On Sun, May 15, 2022 at 7:21 AM Greg Werbin <outth...@me.gregwerbin.com> wrote: > Currently, resources must be individual files inside a package. A > directory cannot itself be a "resource". According to the docs, " a *resource* is a binary artifact that is shipped within a package." a directory is not a binary artifact -- it can't have actually data in it like a file can. So I'm not sure how it wouel make sense for a directory to be a resource. > my_great_app/ > __init__.py > something.py > data/ > assets/ > images/ > a.png > a.png > c.png > > Each of data/ assets/ and images/ must also be a package, with its own > __init__.py file. You cannot access the resource data/assets/images/a.png > in the package my_great_app, you must access the resource a.png in the > package my_great_app.data.assets.images. This is (in my opinion) > unintuitive, easy to forget, and moderately annoying. > It doesn't seem that bad to me -- my thoughts is that if you have that much structure to your resources, maybe the resource system is not the right tool for the job. nevertheless ... > Alternatively, if for some reason directories cannot themselves be > resources, allowing file resources in subdirectories (without creating a > new subpackage) would also be a nice ergonomic improvement. > That might be possible, and would make sense to me. However, the entire point of resources is to provide an abstraction -- the individual resources may not be files on disk at all -- so extending the nested path concpet may not make sense. That being said, I also note that importlib.abc.ResourceReader is an ABC -- so I think you could very well make your own ResourceReader that could traverse a directory hierarchy if you wanted to. """ And the contents() method is defined as: Returns an iterable of strings over the contents of the package. Do note that it is not required that all names returned by the iterator be actual resources, e.g. it is acceptable to return names for which is_resource() would be false. Allowing non-resource names to be returned is to allow for situations where how a package and its resources are stored are known a priori and the non-resource names would be useful. For instance, returning subdirectory names is allowed so that when it is known that the package and resources are stored on the file system then those subdirectory names can be used directly. """ which implies to me that the system is expected to optionally handle subdirs. Perhaps you can write a ResourceResader that meets your needs, and it turns out to be generally useful, it could be later added to the stslib. -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/7QTDMP6CASWOA7HQ3PWKZGSQOUMPQ4GO/ Code of Conduct: http://python.org/psf/codeofconduct/
