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

Nathaniel Smith njs at pobox.com
Mon May 7 07:42:00 EDT 2018


On Mon, May 7, 2018, 03:45 Steven D'Aprano <steve at pearwood.info> wrote:

> On Sun, May 06, 2018 at 09:33:03PM -0700, Nathaniel Smith wrote:
>
> > How is
> >
> > data_path = __filepath__.parent / "foo.txt"
> >
> > more distracting than
> >
> > data_path = joinpath(dirname(__file__), "foo.txt")
>
>
> Why are you dividing by a string? That's weird.
>
> [looks up the pathlib docs]
>
> Oh, that's why. It's still weird.
>
> So yes, its very distracting.
>

Well, yes, you do have to know the API to use it, and if you happen to have
learned the os.path API but not the pathlib API then of course the os.path
API will look more familiar. I'm not sure what this is supposed to prove.


> First I have to work out what __filepath__ is, then I have to remember
> the differences between all the various flavours of pathlib.<whatever>Path
> and suffer a moment or two of existential dread as I try to work out
> whether or not *this* specific flavour is the one I need. This might not
> matter for heavy users of pathlib, but for casual users, it's a big,
> intimidating API with:
>
> - an important conceptual difference between pure paths and
>   concrete paths;
> - at least six classes;
>

The docs could perhaps be more beginner friendly. For casual users, the
answer is always "you want pathlib.Path".

- about 50 or so methods and properties
>

Yeah, filesystems have lots of operations. That's why before pathlib users
had to learn about os and os.path and shutil and glob and maybe some more
I'm forgetting.


> As far as performance goes, I don't think it matters that we could
> technically make pathlib imported lazily. Many people put all their
> pathname manipulations at the beginning of their script, so lazy or not,
> the pathlib module is going to be loaded *just after* startup, .
>
> For many scripts, this isn't going to matter, but for those who want to
> avoid the overhead of pathlib, making it lazy doesn't help. That just
> delays the overhead, it doesn't remove it.
>

AFAIK were two situations where laziness has been mentioned in this thread:

- my suggestion that we delay loading pathlib until someone accesses
__filepath__. I don't actually know how to implement this so it was mostly
intended to try to spur new ideas, but if we could do it, the point of the
laziness would be so that scripts that didn't use __filepath__ wouldn't pay
for it.

- Nick's observation that pathlib could load faster if it loaded fnmatch
lazily. Since this is only used for a few methods, this would benefit any
script that didn't use those methods. (And for scripts that do need
fnmatch's functionality, without pathlib they'd just be importing it
directly, so pathlib importing it isn't really an extra cost.)

It's true that laziness isn't a silver bullet, though, yeah. We should also
look for ways to speed things up.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180507/9070c4d4/attachment-0001.html>


More information about the Python-ideas mailing list