<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 8 Apr 2016 at 14:23 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 Fri, Apr 8, 2016 at 8:34 PM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
> On Fri, 8 Apr 2016 at 09:39 Ethan Furman <<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>> wrote:<br>
>> > I thought the whole point off all this is that not any old string can be<br>
>> > a path! (whereas any int can be an index). Unless we go with Chris A's<br>
>> > suggestion that this be a more generic lossless string protocol, rather<br>
>> > than just for paths.<br>
>><br>
>> That does seem to be a valid point against str.__fspath__.<br>
><br>
> Yep, and I'm expecting we won't want that at this point. The fact that paths<br>
> need strings for low-level OS stuff is a historical and technical detail, so<br>
> no need to drag the entire str type into it if we can provide a reasonable<br>
> helper function (for either the ABC or magic method solution).<br>
<br>
I'm not sure I understand what these points are about.</blockquote><div><br></div><div>It means we most likely won't add a new method to str in regards to this proposal.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Anyway,<br>
disallowing str or bytes as pathnames will break backwards<br>
compatibility if done at some point in the future. There's no way<br>
around that.<br></blockquote><div><br></div><div>No one is proposing disallowing str or bytes for a pre-existing API that supports either. The whole point of this is to make APIs work with strings and pathlib.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But regarding all this talk of mine about bytes is because it has not<br>
been completely clear to me if something can break when converting a<br>
bytes path to str. I did originally propose guaranteeing a str, but I<br>
am so far only 85% convinced that that does not cause any problems.</blockquote><div><br></div><div>Depends on your definition of "problem". If you somehow blindly converted a bytes object representing a path to a str without knowing its encoding you will definitely break someone silently (and even os.fsdecode() isn't fool-proof thanks to multiple encodings on a single file system).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I<br>
understand that fsencode(fsdecode(bytes_path)) should always be equal<br>
to bytes_path. But can some other path operations fail when there are<br>
surrogates in the strings? And again, not to forget DirEntry, which<br>
may have a byte string path.<br></blockquote><div><br></div><div>At this point no one wants to touch bytes paths. If you need that level of control because of multiple encodings within a single file system then you will probably have to stick with managing bytes paths on your own to get the encoding right.</div><div><br></div><div>And just because DirEntry supports bytes doesn't mean that any magic method it gains has to carry that forward (it can always raise a TypeError if necessary).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Either way, I suppose os.fspath should accept anything that has<br>
__fspath__ or is a str or bytes (whether these have the dunder method<br>
or not).</blockquote><div><br></div><div>Maybe. I'm not sure if we will want to down that route of both bytes and str being supported out of the same function as that gets messy quickly. The main reason os.scandir() supports it is so it can be a drop-in replacement for os.listdir(). It really depends on how we choose to structure the function in terms of just doing the right thing for objects that follow the protocol or if we want to introduce some required structure for the resulting path and implement some type guarantees so you have a better idea of what you will be working with after calling the function.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Then the options are either to return Union[str, bytes] or to<br>
always return str. And if the latter does not cause any problems, I<br>
like it way better, and it seems others would do too. </blockquote><div><br></div><div>You don't have to convert byte paths to str, you can simply raise an exception in the face of them.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And in that case<br>
it would probably be time to deprecate bytes paths on posix too (on<br>
Windows, this is already the case).<br></blockquote><div><br></div><div>Can't do that as Stephen Turnbull will tell you. :) At best we can marginalize the support of bytes-based paths to only low-level APIs exposed through the os package.</div><div><br></div><div>-Brett</div></div></div>