Showing content from http://mail.python.org/pipermail/python-dev/attachments/20160411/69d01ce6/attachment.html below:
<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 11 Apr 2016 at 11:28 Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/11/2016 10:36 AM, Brett Cannon wrote:<br>
> On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote:<br>
<br>
>> I'm not saying that bytes paths are common -- and if this was a<br>
>> brand-new feature I wouldn't be pushing for it so hard;Â however, bytes<br>
>> paths are already supported and it seems to me to be much less of a<br>
>> headache to continue the support in this new protocol instead of drawing<br>
>> an artificial line in the sand.<br>
><br>
> Headache for you? The stdlib? Library authors? Users of libraries? There<br>
> are a lot of users of this who have varying levels of pain for this.<br>
<br>
Yes, yes, maybe, maybe. :)<br>
<br>
>> Asked another way, what are we gaining by disallowing bytes in this new<br>
>> way of getting paths versus the pain caused when bytes are needed and/or<br>
>> accepted?<br>
><br>
> Type consistency. E.g. if I pass in a DirEntry object into os.fspath()<br>
> and I don't know what the heck I'm getting back then that can lead to<br>
> subtle bugs [...]<br>
<br>
> How about we take something from the "explicit is better than implicit"<br>
> playbook and add a keyword argument to os.fspath() to allow bytes to<br>
> pass through?<br>
><br>
>Â Â def fspath(path, *, allow_bytes=False):<br>
>Â Â Â Â if isinstance(path, str):<br>
>Â Â Â Â Â Â return path<br>
>Â Â Â Â # Allow bytearray?<br>
>Â Â Â Â elif allow_bytes and isinstance(path, bytes):<br>
>Â Â Â Â Â Â return path<br>
>Â Â Â Â try:<br>
>Â Â Â Â Â Â protocol = path.__fspath__()<br>
>Â Â Â Â except AttributeError:<br>
>Â Â Â Â Â Â pass<br>
>Â Â Â Â else:<br>
>Â Â Â Â Â Â # Explicit type check worth it, or better to rely on duck typing?<br>
>Â Â Â Â Â Â if isinstance(protocol_path, str):<br>
>Â Â Â Â Â Â Â Â return protocol_path<br>
>Â Â Â Â raise TypeError("expected a path-like object, str, or bytes (if<br>
> allowed), not {type(path)}")<br>
<br>
I think that might work. We currently have four path related things:<br>
bytes, str, Path, DirEntry -- two are str-only, one is bytes-only, and<br>
one can be either.<br>
<br>
I would write the above as:<br>
<br>
  def fspath(path, *, allow_bytes=False):<br>
   try:<br>
     path = path.__fspath__()<br>
   except AttributeError:<br>
     pass<br>
   if isinstance(path, str):<br>
     return path<br>
   elif allow_bytes and isinstance(path, bytes):<br>
     return path<br>
   else:<br>
     raise SomeError()<br>
<br>
> For DirEntry users who use bytes, they will simply have to pass around<br>
> DirEntry.path which is not as nice as simply passing around DirEntry,<br>
<br>
If we go with the above we allow DirEntry.__fspath__ to return bytes and<br>
still get type-consistency of str unless the user explicitly declares<br>
they're okay with getting either (and even then the field is narrowed<br>
from four possible source types (or more as time goes on) to two.<br></blockquote><div><br></div><div>You get type consistency from so.fspath(), not the protocol, though.</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To recap, this would allow both str & bytes in __fspath__, but the<br>
fspath() function defaults to only allowing str through.<br>
<br>
I can live with that.<br></blockquote><div><br></div><div>I'm -0 on allowing __fspath__ to return bytes, but we can see what others think. </div></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