pathlib
Dan Sommers
2QdxY4RzWzUUiLuE at potatochowder.com
Mon Sep 30 11:49:58 EDT 2019
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
More information about the Python-list
mailing list