On Mon, 2022-05-16 at 14:36 +0000, Greg Werbin wrote: > Non-"binary" resources are already in widespread use, 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." > > Moreover, I see no reason why a resource name in general shouldn't be allowed > to contain a "/" character! Perhaps the simplest way to implement such a thing > is to leave all the existing importlib.resources APIs unchanged, but then add > a separate function that grants access to collections of resources within a > package. Maybe this is as simple as adding a `dir=` kwarg to > importlib.resources.files(), defaulting to `dir=None`. > _______________________________________________ > 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/M34PRCIZGY4ZJIC6KLYNFS6HGJGNXEEX/ > Code of Conduct: http://python.org/psf/codeofconduct/
No, Python source files are resources too. "resource" is an abstract concept akin to files, its propose is to allow support other use-cases than just files on the OS file system (eg. zip file, tarball, database). Adding a "directory" reference goes against the purpose of abstracting the FS away. Packages are akin to directories, files are akin to resources, when operating on a FS. Cheers, Filipe Laíns
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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/4NALFWT6RPNTZPOVX4NZTIPOFZ4ZLMAZ/ Code of Conduct: http://python.org/psf/codeofconduct/
