On Mon, May 7, 2018, 03:45 Steven D'Aprano <steve@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