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). 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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/k7hoven%40gmail.com > _______________________________________________ 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