pathlib

[Dan Sommers]

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.

>> 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.

> 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.  :-)

> 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.