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
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?