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