[Python-Dev] file system path protocol PEP (original) (raw)

Koos Zevenhoven k7hoven at gmail.com
Wed May 11 19:08:03 EDT 2016

On Thu, May 12, 2016 at 1:13 AM, Brett Cannon <brett at python.org> wrote:

On Wed, 11 May 2016 at 13:45 Serhiy Storchaka <storchaka at gmail.com> wrote:

On 11.05.16 19:43, Brett Cannon wrote: > os.path > ''''''' > > The various path-manipulation functions of os.path [#os-path] > will be updated to accept path objects. For polymorphic functions that > accept both bytes and strings, they will be updated to simply use > code very much similar to > path._fspath_() if hasattr(path, '_fspath_') else path. This > will allow for their pre-existing type-checking code to continue to > function. I afraid that this will hit a performance. Some os.path functions are used in tight loops, they are hard optimized, and adding support of path protocol can have visible negative effect. As others have asked, what specific examples do you have that os.path is used in a tight loop w/o any I/O that would overwhelm the performance?

I suggest first implement other changes and then look whether it is worth to add support of path protocol in os.path functions. I see this whole discussion breaking down into a few groups which changes what gets done upfront and what might be done farther down the line: 1. Maximum acceptance: do whatever we can to make all representation of paths just work, which means making all places working with a path in the stdlib accept path objects, str, and bytes.

Since you are putting me in this camp, there is at least one thing you are wrong about. I don't want all places that work with a path to accept bytes. Only those that already do so, including os/os.path. And yes, I think the stdlib should show a good example in accepting path types (especially those provided in the stdlib itself).

Whether Ethan is fully in camp 1, I don't know. Not that I think he would be any closer to the other camps, though.

2. Safely use path objects: fspath() is there to signal an object is a file system path and to get back a lower-level representation so people stop calling str() on everything, providing some interface signaling that someone doesn't misuse an object as a path and only changing path consumptions APIs -- e.g. open() -- and not path manipulation APIs -- e.g. os.path -- in the stdlib.

3. It ain't worth it: those that would rather just skip all of this and drop pathlib from the stdlib. Ethan and Koos are in group #1 and I'm personally in group #2 but I tried to compromise somewhat and find a middle ground in the PEP with the level of changes in the stdlib but being more restrictive with os.fspath(). If I were doing a pure group #2 PEP I would drop os.path changes and make os.fspath() do what Ethan and Koos have suggested and simply pass through without checks whatever path.fspath() returned if the argument wasn't str or bytes.

Related to this, based on the earlier discussions, I had the impression that you were largely in the same camp as me. In fact, I thought you had politely left some things out of the PEP draft so I could fill them in. It turned out I was wrong about that, because you didn't merge them.

-- Koos

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com

More information about the Python-Dev mailing list