pathlib

[DL Neil]

On 2/10/19 12:52 AM, Rhodri James wrote:
> On 01/10/2019 06:03, DL Neil via Python-list wrote:
>> On 30/09/19 9:28 PM, Barry Scott wrote:
>>>> On 30 Sep 2019, at 05:40, DL Neil via Python-list 
>>>> <python-list at python.org> wrote:
>>>>
>>>> Should pathlib reflect changes it has made to the file-system?
>>>
>>> I think it should not.
>>
>> The term "concrete" is applied to Path(), PosixPath(), and 
>> WindowsPath() - whereas the others are differentiated with the prefix 
>> "Pure".
>>
>> I take "concrete" to mean 'existing in reality or real experience'. 
>> Thus, I saw the Pure* entities as supporting abstract paths, but the 
>> concrete entities as representing (and reflecting) real-world (file 
>> system) entities.
>>
>> Thus, there is no need for .exists() to be available in the Pure 
>> paths, but there is when utilising their concrete implementations.
> 
> Sorry but your logic is inconsistent here.  For starters, it's not that 
> there's no need for .exists() in Pure paths, it's that .exists() is 
> meaningless.  Pure paths aren't related to any actual filing system (to 
> paraphrase you), so existence isn't an option.
> 
> However if you insist that "concrete" means "existing in reality", then 
> .exists() is unnecessary because by your very definition the path must 
> exist.  The very act of creating the Path object would create the 
> corresponding file or directory.  So either pathlib does something 
> horrific, or your definition is wrong.


Very good! Yes, I'd picked-on .exists() purely (hah!) because it does 
not appear in PurePaths, but does in concrete Paths.

That said, it is one of the ways that a path can be shown to transition 
from some 'pure' state to become 'concrete'.

However, A.N.Other has suggested that I might be mis-applying the word 
"concrete", so maybe not. On which topic, I went looking for a decent 
technical definition of the word, but instead of coming-out smiling, 
I've been left somewhat stony-faced (hah, hah!).

A definition/description would be useful. Any pointers?


 > Consider for a moment:
 >
 >      rhodri at scrote:~$ cat /home/rhodri/foo.txt
 >      cat: /home/rhodri/foo.txt: No such file or directory
 >
 > cat "concatenates files" to quote its man page.  Does that mean it
 > creates them if they don't exist, just because I typed the name into the
 > command?  No.  I wouldn't expect it either.  In exactly the same way I
 > don't expect a concrete file*name* to necessarily refer to an actual 
file.


I haven't followed this point: throwing a non-existent file at cat 
produces an err.msg. Neither of us are surprised! However, we know 
exactly which path was/paths were used, and where (at least the first) 
error was found.


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.


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?


Regarding this discussion: I've been able to take points-raised and 
learn, even to decide on some tactics for future use. Thanks to all who 
have contributed wisdom...
-- 
Regards =dn