<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 19 Apr 2016 at 04:46 Stephen J. Turnbull <<a href="mailto:stephen@xemacs.org">stephen@xemacs.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Brett Cannon writes:<br>
 > On Mon, 18 Apr 2016 at 12:26 Stephen J. Turnbull <<a href="mailto:stephen@xemacs.org" target="_blank">stephen@xemacs.org</a>> wrote:<br>
<br>
 > Well, it makes *your* head hurt;<br>
<br>
It doesn't, because I have a different (and IMHO better) model.  I can<br>
interpret yours without pain by comparing to that.<br>
<br>
 > By providing os.fspath() I can say that I do not, under any<br>
 > circumstances, want someone to guess at the encoding some bytes<br>
 > path is under to get me a string and instead I want to start and<br>
 > end entirely in a world of strings. IOW os.fspath() lets me work in<br>
 > such a way that the instant bytes are introduced into my code for<br>
 > file paths it triggers a TypeError.<br>
<br>
Does it really help you work that way?  open is polymorphic, and will<br>
use os._raw_fspath(obj, (bytes,str)).  Ditto os.scandir etc.  If they<br>
don't, there's no point in supporting bytes returns from __fspath__,<br>
is there?</blockquote><div><br></div><div>You're leaving out all of the os.path functions, but you're right that if they didn't support it like Windows then this entire discussion of bytes paths would be moot.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  Application code will normally not be calling os.fspath.<br>
In the future, pathlib will, I suppose, but even without os.fspath<br>
pathlib already protects you, as does antipathy.[1]<br></blockquote><div><br></div><div>I disagree that application code won't be calling os.fspath.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
More effective, then, is just to use pathlib for your Path-hacking<br>
work as soon as the path-representing object appears, and Path will<br>
complain about bytes for you.  This is an analogue of the "decode<br>
bytes at the boundary" principle.<br></blockquote><div><br></div><div>Ah, but you see that doesn't make porting easy. If I have a bunch of path-manipulating code using os.path already and I want to add support for pathlib I can either (a) rewrite all of that path-manipulating code to work using pathlib, or (b) simply call `path = os.fspath(path)` and be done with it. Basically if you have written any code that uses os.path then you will have to care about (a) or (b) as a way to add support for pathlib short of the `str(path)` hack we're all working to get away from. And if people truly liked option (a) then this conversation wouldn't be such a big deal as we would have seen more people using pathlib already (yes, the provisional tag may have scared some off, but my guess is it's more from not wanting to rewrite os.path-using code).</div><div><br></div><div>Now if you can convince me that the use of bytes paths is very minimal and thus people doing path manipulations with them will be a very small minority then I'm happy to try and use this to keep pushing people towards avoiding bytes for file paths. But over the years people such as yourself, Stephen, have convinced me that people do some really crazy stuff with their file systems and that it isn't isolated to just one or two people. And so it becomes this situation where we need to ask ourselves if we are going to tell them to just deal with it or help them transition.</div><div><br></div><div>The other way to convince me is that people needing to support older versions of Python will use `path = path.__fspath__() if hasattr(path, '__fspath__') else path` and that allowing bytes with that idiom is going to cost them dearly. My current assumption is that it won't because people using that idiom are using os.path and those functions will complain when mixing str and bytes together, but I'm open to being convinced otherwise.</div><div><br></div><div>I guess what I'm trying to get at is that I understand the desire to get people to get the bytes path habit, but to me the best way will be to get people quickly and easily transitioned over to pathlib as a carrot rather than using the lack of bytes path support in this transition as a stick.</div><div><br></div><div>-Brett</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 > Yep, we are stuck with the names unless you want to propose a new<br>
 > name and deprecate the old one.<br>
<br>
I already proposed fs_ensure_bytes and fs_ensure_str.  I think they're<br>
sufficiently ugly to prove my point.<wink/><br>
<br>
<br>
Footnotes:<br>
[1]  Strictly speaking, antipathy protects you from inadvertant mixing<br>
of bytes and str.<br>
<br>
</blockquote></div></div>