pathlib

[Richard Damon]

On 10/2/19 6:27 PM, DL Neil via Python-list wrote:
> On 3/10/19 3:07 AM, Rhodri James wrote:
>> 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.
>
>
> Nor I, but had assumed (having seen it before) that it was a
> generally-accepted term in OOP that I have yet to learn. Was slightly
> surprised not to find it in any of the/my usual tech.dictionaries.
>
> Obviously, my assumptions/expectations of its meaning were inaccurate
> or incomplete, but I appreciate your efforts to straighten-out it (and
> me)!

My experience is that Concrete is generally thought of as the opposite
of Abstract, you can make an object of a Concrete type, but not one of
an Abstract type. That doesn't quite apply here as PurePath isn't an
Abstract class in this sense, as you CAN create objects of type
PurePath. An Abstract class would be something like Iterable which is
(as far as I know) an Abstract Base Class which objects can have as a
'base' but can't be just of that type.

I am not sure that Concrete is really the right term here, but the
beginning of the documentation for Pathlib does sort of define what it
means here:

Path classes are divided between pure paths
<https://docs.python.org/3/library/pathlib.html#pure-paths>, which
provide purely computational operations without I/O, and concrete paths
<https://docs.python.org/3/library/pathlib.html#concrete-paths>, which
inherit from pure paths but also provide I/O operations.

So for Pathlib, Concrete means that it provides access to I/O operations
and thus can only handle paths of the flavor of the OS the program is
running on.

-- 
Richard Damon