Re: Loading Resources From a Python Module/Package

On 1 February 2015 at 15:28, Nick Coghlan <[email protected]> wrote:
> * I don't think we should couple the concept of resource anchors
> directly to package names (as discussed, it doesn't work for namespace
> packages, for example). I think we *should* be able to *look up*
> resource anchors by package name, although this may fail in some cases
> (such as namespace packages), and that the top level API should do
> that lookup implicitly (allowing package names to be passed wherever
> an anchor is expected). A module object should also be usable as its
> own anchor. I believe we should disallow the use of filesystem paths
> as resource anchors, as that breaks the intended abstraction (looking
> resources up relative to the related modules), and the API behaviour
> is clearer if strings are always assumed to be referring to
> package/module names.

Oops, just realised this is wrong, because I myself initially used the
term "resource anchor" to refer to two different things and didn't go
back to fix this point when I settled on only using it to refer to
part of the API between the import machinery and custom resource
loaders.

To fix that mistake:

* I think the user facing API should be defined in terms of modules &
packages (as in Donald's draft API), provided by name, spec or the
object itself.

* I think the interface between the import machinery and resource
loaders should use the concept of "resource anchors" as a new term to
describe what we mean when __file__ gets set to something other than a
real filesystem path. Filesystem paths are then a kind of resource
anchor, as are the combinations of a zip archive name with a subpath
within that archive.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia