On 10/2/19 4:14 AM, DL Neil via Python-list wrote:
In the case that sparked this enquiry, and in most others, there is no need for a path that doesn't actually lead somewhere. The paths that are used, identify files, open them, rename them, create directories, etc. The idea of a path that just 'exists' (sorry!), without being part of some purpose, seems odd.
Think about preferences. Users can put preferences in (e.g.) ~/.config/prefs, admins might provide "local" preferences in /etc/prefs, and the developers might provide fallback preferences in /etc/prefs. When the application starts up, it could have a list of paths to files that may or may not exist. Or think about the shell in that failed "cat" command. It's possible that cat created a path from what the user typed and then tried to open it. For that brief moment, cat had a path to a file that didn't exist, however un-useful it may have been.
At this time (and assuming that after two (separate) incidents dragging me away to solve other people's problems, I intend to stick with trying to get my head around pathlib - even if I have to sub-class it (which my reading shows is another 'can of worms'). So, 'reading' is about all I've accomplished since the original post. Sadly, the majority of posts seem to have come from other confused-minds - many of whom seemed to be giving-up in disgust. If true, such represents TWO failures! I'm sure that the designer(s) had a clear vision (having watched previous attempts rise-and-fall), but per earlier in this discussion, maybe the explanation and 'vision' could be better communicated to us simple-boys?
I don't think anyone gave up in disgust. Yes, there was some disagreement, and now the discussion has slowed or stopped, but I think your original question was answered: Path objects, apparently by an arguably questionable design, fail to meet your expecation, and some simple changes end up breaking backwards compatibility. Maybe a documentation change could prevent others from experiencing the same expectation failure. Maybe you could implement one of the proposed changes in a private library function as a workaround? -- https://mail.python.org/mailman/listinfo/python-list
