osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

pathlib


On 3/10/19 6:25 AM, Barry Scott wrote:
>> On 2 Oct 2019, at 09:14, DL Neil via Python-list 
>> <python-list at python.org <mailto:python-list at python.org>> wrote:
>> 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 <mailto: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.
>>
> 
> 
>> 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!).
> 
> "concrete
> 
>   *
>     adj.
>     Of or relating to an actual, specific thing or instance; particular.
>     "
> 
> 
>> 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.
> 
> Concrete means a specific operating system's filesystem rules, Windows 
> or Posix.

At last the gears have stopped grinding! (cement dust?)

The distinction of "pure", as distinct from "concrete", was readily grasped.

The idea that "concrete" refers to FS rules, cf files on the FS, has 
been what so many have been battling to lodge between my ears. Well done!

Also, nicely stated.

In view of my not being the only one to arrive with similar 
expectations, do you/we feel that this is carefully and sufficiently 
conveyed within the (PSL) documentation?
-- 
Regards =dn