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
Rhodri James *-* Kynesim Ltd