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
<2qdxy4rzwzuui...@potatochowder.com
<mailto:2qdxy4rzwzuui...@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
--
https://mail.python.org/mailman/listinfo/python-list
