<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 11, 2016 at 10:40 PM, Greg Ewing <span dir="ltr"><<a href="mailto:greg.ewing@canterbury.ac.nz" target="_blank">greg.ewing@canterbury.ac.nz</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the ONLY thing<br>
you should do with it is pass it along to another low level system<br>
call.<br>
</blockquote>
<br></span>
Not quite -- you can separate it into components and<br>
work with them. Essentially the same set of operations<br>
that os.path provides.<br></blockquote><div><br></div><div>ahh yes, so while posix claims that paths are "just a char*", they are really bytes where we can assume that the byte with value 2F is the pathsep (and that 2E separates an extension?), so I suppose os.path is useful. But I still think that most of us should never deal with bytes paths, and the few that need to should just work with the low level functions and be done with it.</div><div><br></div><div>One more though came up just now: there are different level sof abstractions and representations for paths. We don't want to make Path a subclass of string, because Path is supposed to be a higher level abstraction -- good.</div><div><br></div><div>then at the bottom of the stack, we NEED the bytes level path, because that what ultimately gets passed to the OS.</div><div><br></div><div>THe legacy from the single-byte encoding days is that bytes and strings were the same, so we could let people work with nice human readable strings, while also working with byte paths in the same way -- but those days are gone -- py3 make s clear (and important) distiction between nice human readable strings  and the bytes that represent them.</div><div><br></div><div>So: why use strings as the lingua franca of paths? i.e. the basis of the path protocol. maybe we should support only two path representations:</div><div><br></div><div>1) A "proper" path object -- i.e. pathlib.Path or anything else that supports the path protocol.</div><div><br></div><div>2) the bytes that the OS actually needs.</div><div><br></div><div>this would mean that the protocol would be to have a __pathbytes__() method that woulde return the bytes that should be passed off to the OS.</div><div><br></div><div>A posix Path implementation could store that internal bytes representation, so it could pass it off unchanged if that's all you need to do.</div><div><br></div><div>Any current API that takes bytes could be made to easily work.</div><div><br></div><div>I'm SURE I'm missing something really big here, but it seems like maybe it's better to get farther from "strings as paths" rather than closer to it....</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>