> There are myriad other practical reasons. Here are some:
Thanks for taking the time to respond with the details - they are good data points
to think about!
> Lastly, there are social reasons. It's just hard to convince most engineers
> to use things like pkg_resources or pkgutil to manipulate resources
> when for them the status quo is just using __file__. Bizarrely the social
> challenges are just as hard as the abovementioned technical challenges.
I agree it's bizarre, but sadly it's not surprising. People get used to certain ways
of doing things, and a certain kind of collective myopia develops when it
comes to looking at different ways of doing things. Having worked with fairly
diverse systems in my time, ISTM that sections of the Python community have
this myopia too. For example, the Java hatred and PEP 8 zealotry that you see
here and there.
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__.
I know Daniel has said he wanted some concept of a listdir() on loaders so that they could basically act as a virtual file system for packages, but it would also require locking down what relative vs. absolute paths meant in get_data/set_data (i.e. is it relative to the loader in the package or the package itself? My pref is the latter for the case of reused loaders) and really pushing people to use the loader APIs for reading intra-package "files".