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
--
https://mail.python.org/mailman/listinfo/python-list
