On Wed, 11 May 2016 at 16:08 Koos Zevenhoven <k7ho...@gmail.com> wrote:
> On Thu, May 12, 2016 at 1:13 AM, Brett Cannon <br...@python.org> wrote: > > > > > > On Wed, 11 May 2016 at 13:45 Serhiy Storchaka <storch...@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). > 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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
