pathlib

[DL Neil]

On 1/10/19 2:58 PM, Dan Sommers wrote:
> On 9/30/19 3:56 PM, Barry Scott wrote:
>>> On 30 Sep 2019, at 16:49, Dan Sommers 
>>> <2QdxY4RzWzUUiLuE at potatochowder.com 
>>> <mailto:2QdxY4RzWzUUiLuE at potatochowder.com>> wrote:
> 
>>> In the totality of a Path object that claims to represent paths
>>> to files,
>>
>> It represents string that *should* in most cases work in the APIs
>> that work on files. Not the same idea.
> 
> I'm not sure the documentation supports your view.  Components
> of paths are strings, but IMO the Path object represents a file.

Worse! There may be an argument for suggesting that the documentation 
supports both descriptions...


>>> including the arguably troublesome read_bytes and
>>> write_bytes methods, and a rename method, however, it's not
>>> unreasonable expect the object to track *itself* when I use *its*
>>> own rename method (backwards compatibility restraints
>>> notwithstanding).
>>
>> "the object" did track the changes its just that "the object" is not
>> the Path object, it's in the operating system and/or the file system.
>> For the rename it's the directory that the name is recorded in.
> 
> So which is it?  Does the Path object represent a string, the
> name of a file (whether that file exists or not), or the file
> itself?  A moment ago, you claimed that a Path object represents
> a string that should work in the APIs that work on files.  Now,
> you're claiming that the Path object is a proxy for something in
> the filesystem.  I don't mean to be combative or confrontational,
> but I think that this fuzziness/inconsistency is at or near the
> root of the differing expectations.

Yes, see earlier comment about "confusion" - in both the minds of 
learners/newcomers and those who are 'experienced'.


>> There was an interest talk at this years PYCON UK about the
>> the errors that people new to python make. Misunderstand syntax
>> is about 1/3 of the problems, but 2/3 was having the wrong model.
>>
>> This discussion seems to fall into the "wrong model" world that
>> leads to a expectation failure.
> 
> On this (that there's something about the model of Path objects
> that leads to expectation failures) we agree.  :-)

Are we talking about "Here's Your Mistake" 
(https://www.youtube.com/watch?v=7gMOaWdzDSw)?

You've strayed into my research area: cognitive psychology - 
understanding how people learn. Whilst we do indeed talk about "models" 
- a person's understanding of how things work and/or how they fit together.

"Models" in the computing world are more often called "abstractions". 
Every?most computer program(mes) are, by definition, an abstraction of 
some real-world event, calculation, or whatever. A Person() class might 
have the name of a real-person, but it is definitely not that (or any 
other) person. It is an abstraction (and likely only of 'part' of that 
person). That said, if the person changes his/her name by Deed Poll 
(legal process) to "Slinky Python", then it would be insulting to use 
the previous name(s)! (and if someone has divorced and re-married, 
never, never, NEVER use the names of the original him+her when referring 
to the 'new' him+her!!!)
(PC alert: traditional pairing described)

You will observe that the original post attempts to paint a picture of 
the model I expected. Since then, several folk have taken me up on the 
request for "good reasons ... why not", and thus, as you say, enabled 
the replacement (education) of my "wrong model", with "the real thing".

 From where do people acquire their models? The YouTube video briefly 
touched-on this. Most commonly: previous experience - thus math students 
write formulae as description, and can come to grief when Python code 
insists upon a sequence of instructions.

So, next time someone tells you to 'read the code' you will wonder why 
the built-in 'documentation' isn't up-to-snuff; and when someone says 
RTFM you'll also realise that you've invited the person to construct 
their own model - an error-prone process at best; and that is why, if 
one examines the rate of adoption for (open source) languages and 
libraries, the greatest influence is the presence/absence of quality 
tutorials - materials designed to encourage the building of congruent 
mental models!


In this discussion we've heard people comparing pathlib with previous 
facilities in os and sys. That's unfortunate because reading the PEP 
shows an intention to diverge.

At the same time, and again reviewing this discussion, you can observe 
two models: one more abstract ("Pure") and the other more oriented to 
reflecting the FS ("concrete"). The gap between is the importance one 
places on each of the two models. Favoring the abstract means seeing the 
Pure constructs as important and the concrete as lesser. The more 
practical view asking for a means to access the file system, sees the 
Pure model as a foundation.

>> Have we moved on to how we can improve the situation?
> 
> Absolutely.
> 
> Documenting the fact that calling rename on a Path object does
> not update that object, and at least an acknowledgement of the
> backwards compatibility issues, would be a good start.  Does the
> same sort of thing happen with Path.chmod as well?
> 
> Clarifying what a Path object represents is also in order.  Again,
> I note that the top of https://docs.python.org/3/library/pathlib.html
> talks about filesystem paths, but a lot of the method descriptions
> (e.g., rename) use the phrase "this file," as if Path objects
> represent (or are actually proxies for) actual files or an actual
> filesystem.

+1

I'm hoping that the snippet taken directly from 'the manual' (see 
earlier post) showing that if the .rename()'s argument is a Path rather 
than a str, the author's intentions (and his model) become easier to 
follow. (help() docs don't though)

That said, if pathlib is not really 'for' file system operations, or 
only handles some of such (and not other(s) that I would like), then 
I'll happily go back/go elsewhere; and the great thing is that we are 
free to make up our own minds and to do things differently from 
each-other, if we want. ie YMMV!


I've learned a lot from this discussion. Thanks!
-- 
Regards =dn