pathlib

[DL Neil]

On 3/10/19 12:42 AM, Dan Sommers wrote:
> 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.

This is an excellent example. Without thinking I would have left such 
as-is. However, what I'm taking-in, is that in order to gain advantage 
from the semantic meaning inherent in the Path class(es), I shouldn't 
leave these as strings (the way they arrive from (current) config 
files*) but they should be defined as (Pure) Paths in the same way that 
numbers will probably be converted from string inputs. As you say, 
because system-defaults may be over-ridden by user-prefs, there's no 
point in 'proving' that such a file exists - such can wait until we 
actually issue the .open()

That said, surely we would still use a 'concrete' class, in case?


* in the case of YAML files, might we even be able to define those 
values as Path()-s...


> 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

Late at night: I used the word "posts" twice, to describe two quite 
different communications. Apologies

The subject of that comment was the (other) research/reading I've been 
doing. No-one on THIS list has given the impression of wanting to dump 
pathlib (which encourages my persisting).

Certainly, although some may have quietly given-up talking to a non-OOP 
native - and one so 'slow', I am appreciative of all help-given!


> disagreement, and now the discussion has slowed or stopped, but  > 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.

As discussed previously, and elsewhere (just now).


> Maybe you could implement one of the proposed changes in a private
> library function as a workaround?

In my mind, I'm wondering if it will come to that (having 'got past' the 
original observation/issue, I'm concerned by .rename()'s silent errors, 
for example). However, that 'outside' research, eg StackOverflow, shows 
that sub-classing pathlib is problematic, and quite possibly not part of 
the design (this is repeating 'gossip' - I'm not going to try to justify 
the comment or the claim). That said, last night my code sub-classing 
Path() seemed to work quite happily (albeit only tested on a 'Posix' 
box). The yawning chasm/gaping jaws below, however, are that I've 
probably made yet another 'assumption' about how things 'should' work. 
Run for the hills!

This was supposed to be a simple, down-time task; a learning-opportunity 
re-factoring code to use a new (er, um, as of v3.4) library...

Thanks again!
-- 
Regards =dn