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

[Nick Coghlan]

On 7 May 2018 at 20:44, Steven D'Aprano <steve at pearwood.info> wrote:

> 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;
> - about 50 or so methods and properties
>

Right, but that's why I think this may primarily be a docs issue, as for
simple use cases, only one pathlib class matters, and that's "pathlib.Path"
(which is the appropriate concrete path type for the running platform),
together with its alternate constructors "Path.cwd()" and "Path.home()".

So if you spell out the OP's original example with pathlib instead of
os.path, you get:

from pathlib import Path
SRC_DIR = Path(__file__).parent


And then SRC_DIR is a rich path object that will mostly let you avoid
importing any of:

- os
- os.path
- stat
- glob
- fnmatch


> 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, .
>

It's the fnmatch and re module imports *inside* pathlib that may be worth
making lazy, as those currently account for a reasonable chunk of the
import time but are only used to implement PurePath.match and
_WildcardSelector. That means making them lazy may allow folks to avoid
those imports if they don't use any of the wildcard matching features.


> 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.
>

That's fine - it's not uncommon for folks looking to minimise startup
overhead to have to opt in to using a lower level API for exactly that
reason.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180507/6c32236d/attachment.html>