On Wed, 11 May 2016 at 16:08 Koos Zevenhoven
On Thu, May 12, 2016 at 1:13 AM, Brett Cannon
wrote: On Wed, 11 May 2016 at 13:45 Serhiy Storchaka
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
wrote: 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).
That's actually what I meant. I'm not advocating widening the APIs that accept bytes at all. -Brett
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.