pathlib

[Dan Sommers]

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?