On Sat, 1/2/14, Brett Cannon <brett@python.org> wrote:
PEP 302 tried to unify this with get_data() and set_data() on loaders, but prior to Python 3.3 you just didn't have any guarantee that __loader__ would even be set, let alone have a loader with those methods. Paul can tell me if my hunch is off, but I assume the dream was that people would do `__loader__.get_data('asset.txt')` instead of `os.path.join(os.path.dirname(__file__), 'asset.txt')` to read something bundled with your package. But as Brian has pointed out, people just have habits at this point of assuming unpacked files and working off of __file__.
Right, and one question is whether we need to educate people away from this way of doing things. In the distlib.resources module I've tried to work around things like the absence of __loader__ that you mention, and to provide a uniform API for accessing package resources whether in file system or zip, using the PEP 302 machinery whenever possible, and filling in some of the gaps that pkgutil has and which pkg_resources attempts to fill.
My pref is [...] and really pushing people to use the loader APIs for reading intra-package "files".
+1
Maybe the Packaging Users Guide could have a Recommended Deployment Strategies section [...] (especially if the instructions work on all platforms, i.e. no symlink discussions)
+1 again. Regards, Vinay Sajip