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

Brett Cannon brett at python.org
Wed May 11 21:03:49 EDT 2016

On Wed, 11 May 2016 at 15:13 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. 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.

I should mention there's also a side group who really wanted to either minimize bytes usage in all of this or not have a polymorphic os.fspath(), hence why that function is defined the way it is around only returning strings in the PEP.

IOW the PEP is already an attempt at compromise and if we can't find a consensus somehow I'll update the PEP to directly reflect my personal preferences and let others write their own competing PEPs if they prefer (but I think it's in everyone's best interests if that's a last resort). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160512/89a1ce61/attachment-0001.html>

More information about the Python-Dev mailing list