Currently, files() requires a parameter indicating from which package to load the resources. A common practice is to pass __package__, meaning load resources from the same package that this module is in.
When #203 is solved, it also becomes possible to use files(__name__) to mean the same thing (load resources from the same package that this module is in or for non-package modules other resources found alongside this module).
Perhaps it would be cleaner and simpler to support files() with no parameter, meaning the same thing (load resources alongside this module). No doubt, this form is the most common usage of files(). Alternately, files could accept the special value "." with the same meaning.
Either implementation would require importlib resources to infer the module from the caller's context. This feature would be an anti-feature if that couldn't be inferred reliably on all Python implementations.
Currently,
files()requires a parameter indicating from which package to load the resources. A common practice is to pass__package__, meaning load resources from the same package that this module is in.When #203 is solved, it also becomes possible to use
files(__name__)to mean the same thing (load resources from the same package that this module is in or for non-package modules other resources found alongside this module).Perhaps it would be cleaner and simpler to support
files()with no parameter, meaning the same thing (load resources alongside this module). No doubt, this form is the most common usage offiles(). Alternately,filescould accept the special value "." with the same meaning.Either implementation would require importlib resources to infer the module from the caller's context. This feature would be an anti-feature if that couldn't be inferred reliably on all Python implementations.