On 7 May 2018 at 20:44, Steven D'Aprano <steve@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@gmail.com | Brisbane, Australia