pathlib

[Rhodri James]

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.

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.

-- 
Rhodri James *-* Kynesim Ltd