pathlib

[Dan Sommers]

On 9/30/19 10:33 AM, Barry Scott wrote:
> 
> 
>> On 30 Sep 2019, at 14:20, Dan Sommers 
>> <2QdxY4RzWzUUiLuE at potatochowder.com 
>> <mailto:2QdxY4RzWzUUiLuE at potatochowder.com>> wrote:
>>
>> That's the wording I read.  I inferred that "path-handling operations
>> which don't actually access a filesystem" meant an object that didn't
>> necessarily represent an actual file, and that "provide methods to do
>> system calls on path objects" did indicate an actual file.  From the
>> existence of Path.read_bytes, I inferred that at least some Path objects
>> represent (and operate on) actual existing files.  I've been doing this
>> for a long time, and I may have read my expecations into those words.
> 
> pathlib.Path() adds the semantics of operating system file rules to strings.

pathlib.Path() adds the semantics of OS pathnames to strings

> The addition of open(), read_bytes() etc is a convenience to the programmer.
> Some people consider this a mistake other a great feature.

Regardless of your opinion of those methods, they exist, and
evidently, they lead to arguably unfounded expectations.

Do they rise to the level of a wart that should be deprecated?

I don't know.

Are they practical in a number of use cases?

Probably.

That was my original point:  a Path object backed by OS- and
filesystem- objects and operations is a great idea, but it's
imperfect and it leads some programmers astray.

> You can write this:
> 
> pathlib.Path("name").open()
> 
> Which is the same as:
> 
> open(pathlib.Path("name"))
> 
> Which is the same as:
> 
> open("name")
> 
> You would not expect str to track the file, why expect Path() to?

That's an interesting question.  If you phrase the question like
that, then you're right:  expecting a string to track the content
of a file is a mistake.

In the totality of a Path object that claims to represent paths
to files, 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).

Dan