<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 18 Apr 2016 at 12:26 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>
<br>
> If we continue with the "str is an encoding of file paths",<br>
<br>
It's not. It's a representation, but not an encoding. In Python 3,<br>
encoding means a representation of a character string using bytes.<br>
It's using "encoding" generically for "representation" that makes your<br>
head hurt.<br></blockquote><div><br></div><div>Well, it makes *your* head hurt; for me it helped clarify some things. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> you can then build from "bytes is an encoding of str" to get a<br>
> pyramid of file path encodings: Path -> str -> bytes. I don't think<br>
> this is in any way a controversial view.<br>
<br>
Perhaps not. But it's not particularly useful. ;-) Here's the<br>
pyramid I think about:<br>
<br>
Path<br>
/ \<br>
/ \<br>
V V<br>
str <-> bytes<br>
<br>
That is, str and bytes are interchangeable *without* any knowledge of<br>
paths, which are on a higher level of complexity and abstraction.<br>
Although in pathlib, there's an assumption that paths are serialized<br>
to str which is (implicitly) serialized to bytes when talking to the<br>
OS, this is not necessarily true for other structured path classes, in<br>
particular it is not true for DirEntry (which is a "enhanced<br>
degenerate" path containing only one path segment but also other<br>
useful information about the filesystem object addressed)<br>
<br>
I haven't looked at Antipathy, but I would guess from Ethan's<br>
promotion of bytes paths and concern with efficiency that "bytes<br>
antipaths" do *not* "go through" str to get to bytes, they already are<br>
bytes (in the sense of class inheritance).<br>
<br>
> But that's when I realized that adding __fspath__ support to os.fsdecode()<br>
> and os.fsencode(), they become more coercion functions rather than<br>
> encoding/decoding functions. It also means that os.fspath() has a place<br>
> when you want to say "I only want to encode a file path to str" and avoid<br>
> the decode bit that os.fsdecode() would do<br>
<br>
I don't understand what you're trying to say here. fsdecode currently<br>
does not promise to decode anything, because it's polymorphic,<br>
accepting str and bytes. fsdecode and fsencode already *are* coercion<br>
functions.<br></blockquote><div><br></div><div>And they will continue to be coercion functions. My point is that since they coerce there is no way to use them in a way to dictate that you don't want any str/bytes encoding/decoding to occur without checking the arguments going into the function (i.e. "no guessing about encodings, please"). By providing os.fspath() I can say that I do not, under any circumstances, want someone to guess at the encoding some bytes path is under to get me a string and instead I want to start and end entirely in a world of strings. IOW os.fspath() lets me work in such a way that the instant bytes are introduced into my code for file paths it triggers a TypeError.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's this kind of semantic confusion and broken nomenclature that is<br>
*why* I dislike these polymorphic functions and objects so much. It<br>
is impossible to reason correctly about them. We're stuck with<br>
invoking "practicality" and muddling through. And the names mislead<br>
even experienced Pythonistas.<br></blockquote><div><br></div><div>Yep, we are stuck with the names unless you want to propose a new name and deprecate the old one.</div></div></div>