On 9/30/19 10:33 AM, Barry Scott wrote:
On 30 Sep 2019, at 14:20, Dan Sommers
<2qdxy4rzwzuui...@potatochowder.com
<mailto:2qdxy4rzwzuui...@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
--
https://mail.python.org/mailman/listinfo/python-list
