While importlib.resources looks very good, I'm certain that it can't replace every use of __file__ for accessing files relative to your Python code.

Consider a mini-Web-server written in Python (there are, of course, lots of these) that needs to serve static files. Users of the Web server will expect to be able to place these static files somewhere relative to the directory their code is in, because the files are version-controlled along with the code. If you make developers configure an absolute path, they'll probably use __file__ anyway to get that path, so that it works on more systems than their own without an installer or a layer of configuration management.

If I understand the importlib.resources documentation, it won't give you a way of accessing your static files directory unless you place an '__init__.py' file in each subdirectory, and convert conventional locations such as "assets/css/main.css" into path(mypackage.assets.css, 'main.css').

That's already a bit awkward. But do you even want __init__.py to be in your static directory? Even if you tell the mini-server to ignore __init__.py, when you upgrade to a production-ready server like Nginx and point it at the same directory, it won't know anything about this and it'll serve your __init__.py files as static files, leaking details of your system. So you probably wouldn't do this.

This is one example; there are other examples of non-Python directories that you need to be able to access from Python code, where adding a file named __init__.py to the directory would cause undesired changes in behavior.

Again, importlib.resources is a good idea. I will look into using it in the cases where it applies. But the retort of "well, you shouldn't be using __file__" doesn't hold up when sometimes you do need to use __file__, and there's no universal replacement for it.

(Also, every Python programmer I've met who's faced with the decision would choose "well, we need to use __file__, so don't zip things" over "well, we need to zip things, so don't use __file__". Yes, it's bad that Python programmers even have to make this choice, and then on top of that they make the un-recommended choice, but that's how things are.)

On Mon, 7 May 2018 at 22:09 Barry Warsaw <barry@python.org> wrote:
Yuval Greenfield wrote:

> I often need to reference a script's current directory. I end up writing:
> import os
> SRC_DIR = os.path.dirname(__file__)

The question I have is, why do you want to reference the script's
current directory?

If the answer is to access other files in that directory, then please
consider using importlib.resources (for Python 3.7) and
importlib_resources (for Python 2.7, 3.4-3.6).

__file__ simply isn't safe, and pkg_resources can be a performance
killer.  The problem of course is that if you're writing an application
and *any* of your dependencies use either technique, you are going to
pay for it.  This is exactly why Brett and I wrote importlib.resources.
We wanted a consistent API, that allows custom loaders to play along,
and which is about as efficient as possible, uses Python's import
machinery, and is safe for uses like zipapps.

now-you-don't-have-to-attend-my-pycon-talk-ly y'rs,

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/