Showing content from http://mail.python.org/pipermail/python-dev/attachments/20160512/ae9e58c3/attachment.html below:
<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 11 May 2016 at 16:08 Koos Zevenhoven <<a href="mailto:k7hoven@gmail.com">k7hoven@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, May 12, 2016 at 1:13 AM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
><br>
><br>
> On Wed, 11 May 2016 at 13:45 Serhiy Storchaka <<a href="mailto:storchaka@gmail.com" target="_blank">storchaka@gmail.com</a>> wrote:<br>
>><br>
>> On 11.05.16 19:43, Brett Cannon wrote:<br>
>> > os.path<br>
>> > '''''''<br>
>> ><br>
>> > The various path-manipulation functions of ``os.path`` [#os-path]_<br>
>> > will be updated to accept path objects. For polymorphic functions that<br>
>> > accept both bytes and strings, they will be updated to simply use<br>
>> > code very much similar to<br>
>> > ``path.__fspath__() if hasattr(path, '__fspath__') else path``. This<br>
>> > will allow for their pre-existing type-checking code to continue to<br>
>> > function.<br>
>><br>
>> I afraid that this will hit a performance. Some os.path functions are<br>
>> used in tight loops, they are hard optimized, and adding support of path<br>
>> protocol can have visible negative effect.<br>
><br>
><br>
> As others have asked, what specific examples do you have that os.path is<br>
> used in a tight loop w/o any I/O that would overwhelm the performance?<br>
><br>
>><br>
>><br>
>> I suggest first implement other changes and then look whether it is<br>
>> worth to add support of path protocol in os.path functions.<br>
><br>
><br>
> I see this whole discussion breaking down into a few groups which changes<br>
> what gets done upfront and what might be done farther down the line:<br>
><br>
> 1. Maximum acceptance: do whatever we can to make all representation of paths<br>
> just work, which means making all places working with a path in the stdlib<br>
> accept path objects, str, and bytes.<br>
<br>
Since you are putting me in this camp, there is at least one thing you<br>
are wrong about. I don't want all places that work with a path to<br>
accept bytes. Only those that already do so, including os/os.path. And<br>
yes, I think the stdlib should show a good example in accepting path<br>
types (especially those provided in the stdlib itself).<br></blockquote><div><br></div><div>That's actually what I meant. I'm not advocating widening the APIs that accept bytes at all.</div><div><br></div><div>-Brett</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Whether Ethan is fully in camp 1, I don't know. Not that I think he<br>
would be any closer to the other camps, though.<br>
<br>
> 2. Safely use path objects: __fspath__() is there to signal an object is a file<br>
> system path and to get back a lower-level representation so people stop<br>
> calling str() on everything, providing some interface signaling that someone<br>
> doesn't misuse an object as a path and only changing path consumptions APIs<br>
> -- e.g. open() -- and not path manipulation APIs -- e.g. os.path -- in the<br>
> stdlib.<br>
><br>
> 3. It ain't worth it: those that would rather just skip all of this and drop<br>
> pathlib from the stdlib.<br>
><br>
> Ethan and Koos are in group #1 and I'm personally in group #2 but I tried to<br>
> compromise somewhat and find a middle ground in the PEP with the level of<br>
> changes in the stdlib but being more restrictive with os.fspath(). If I were<br>
> doing a pure group #2 PEP I would drop os.path changes and make os.fspath()<br>
> do what Ethan and Koos have suggested and simply pass through without checks<br>
> whatever path.__fspath__() returned if the argument wasn't str or bytes.<br>
><br>
<br>
Related to this, based on the earlier discussions, I had the<br>
impression that you were largely in the same camp as me. In fact, I<br>
thought you had politely left some things out of the PEP draft so I<br>
could fill them in. It turned out I was wrong about that, because you<br>
didn't merge them.</blockquote></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4