<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 7 May 2018 at 20:44, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
First I have to work out what __filepath__ is, then I have to remember <br>
the differences between all the various flavours of pathlib.<whatever>Path <br>
and suffer a moment or two of existential dread as I try to work out <br>
whether or not *this* specific flavour is the one I need. This might not <br>
matter for heavy users of pathlib, but for casual users, it's a big, <br>
intimidating API with:<br>
<br>
- an important conceptual difference between pure paths and<br>
  concrete paths;<br>
- at least six classes;<br>
- about 50 or so methods and properties<br></blockquote><div><div><br></div><div>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()".<br><br></div><div>So if you spell out the OP's original example with pathlib instead of os.path, you get:<br></div><div><br><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px"><div>from pathlib import Path<br></div><div>SRC_DIR = Path(__file__).parent</div></blockquote><div><br></div><div>And then SRC_DIR is a rich path object that will mostly let you avoid importing any of:<br><br></div><div>- os<br></div><div>- os.path<br></div><div>- stat<br></div><div>- glob<br></div><div>- fnmatch<br></div></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

As far as performance goes, I don't think it matters that we could <br>
technically make pathlib imported lazily. Many people put all their <br>
pathname manipulations at the beginning of their script, so lazy or not, <br>
the pathlib module is going to be loaded *just after* startup, .<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

For many scripts, this isn't going to matter, but for those who want to <br>
avoid the overhead of pathlib, making it lazy doesn't help. That just <br>
delays the overhead, it doesn't remove it.<br></blockquote><div><br></div><div>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.<br><br></div><div>Cheers,<br></div><div>Nick.<br clear="all"></div></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>