<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 13 Apr 2016 at 15:20 Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oh, since others voted, I will also vote and explain my vote.<br>
<br>
I like choice 1, str only, because it's very well defined. In Python<br>
3, Unicode is simply the native type for text. It's accepted by almost<br>
all functions. In other emails, I also explained that Unicode is fine<br>
to store undecodable filenames on UNIX, it works as expected since<br>
many years (since Python 3.3).<br>
<br>
--<br>
<br>
If you cannot survive without bytes, I suggest to add two functions:<br>
one for str only, another which can return str or bytes.<br>
<br>
Maybe you want in fact two protocols: __fspath__(str only) and<br>
__fspathb__ (bytes only)? os.fspathb() would first try __fspathb__, or<br>
fallback to os.fsencode(__fspath__). os.fspath() would first try<br>
__fspath__, or fallback to os.fsdecode(__fspathb__). IMHO it's not<br>
worth to have such complexity while Unicode handles all use cases.<br></blockquote><div><br></div><div>Implementing two magic methods for this seems like overkill. Best I would be willing to do with automatic encode/decode is use os.fsencode()/os.fsdecode() on the argument or what __fspath__() returned.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or do you know functions implemented in Python accepting str *and* bytes?<br></blockquote><div><br></div><div>On purpose, nothing off the top of my head.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
<br>
The C implementation of the os module has an important<br>
path_converter() function:<br>
<br>
 * path_converter accepts (Unicode) strings and their<br>
 * subclasses, and bytes and their subclasses.  What<br>
 * it does with the argument depends on the platform:<br>
 *<br>
 *   * On Windows, if we get a (Unicode) string we<br>
 *     extract the wchar_t * and return it; if we get<br>
 *     bytes we extract the char * and return that.<br>
 *<br>
 *   * On all other platforms, strings are encoded<br>
 *     to bytes using PyUnicode_FSConverter, then we<br>
 *     extract the char * from the bytes object and<br>
 *     return that.<br>
<br>
This function will implement something like os.fspath().<br>
<br>
With os.fspath() only accepting str, we will return directly the<br>
Unicode string on Windows. On UNIX, Unicode will be encoded, as it's<br>
already done for Unicode strings.<br>
<br>
This specific function would benefit of the flavor 4 (os.fspath() can<br>
return str and bytes), but it's more an exception than the rule. I<br>
would be more a micro-optimization than a good reason to drive the API<br>
design.<br></blockquote><div><br></div><div>Yep, it's interesting to know but Chris and I won't let it drive the decision (I assume).</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Victor<br>
<br>
Le mercredi 13 avril 2016, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> a écrit :<br>
><br>
> <a href="https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1" rel="noreferrer" target="_blank">https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1</a> has the four potential approaches implemented (although it doesn't follow the "separate functions" approach some are proposing and instead goes with the allow_bytes approach I originally proposed).<br>
</blockquote></div></div>