[Python-ideas] __dir__ in which folder is this py file

[Rob Speer]

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 at 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,
> -Barry
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180515/053a184c/attachment.html>