pathlib

[Rhodri James]

On 02/10/2019 09:14, DL Neil via Python-list wrote:
> 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?

I think we're looking at a philosophical split, so I'd look in that 
direction rather than for technical terminology.

My rough and ready definition *in this instance* relies on observing 
that we are supposed to contrast "pure" and "concrete" and going from there.

The overriding thing for me is that paths are names.  Just names.  They 
have a particular syntax, but that's all.  This is obviously true for 
pure paths, which are clearly abstractions. 
PurePath("/home/rhodri/foo.txt") cannot refer to a real file because it 
has no mechanisms for relating to reality.  It can only be a name, and 
all the PurePath class gives us is convenient mechanisms for 
manipulating that name within its syntactic rules.

Concrete paths are not pure paths.  Literally, in logic terms.  Pure 
paths cannot refer to real file, concrete paths can refer to real files. 
  They don't necessarily do so otherwise we have a massive excluded 
middle.  Path("/home/rhodri/foo.txt") may or may not actually exist on 
any computer.  It may refer to a file, and by the end of this sentence 
it may refer to a different file to what it was at the start.  The only 
sensible interpretation I can see is that it is still a name, just one 
that may transiently be related to a real object.

Concrete may not be the best term for this, but I can't think of a 
better one.

-- 
Rhodri James *-* Kynesim Ltd