On 04/14/2016 06:56 AM, Victor Stinner wrote:
> 2016-04-14 15:40 GMT+02:00 Nick Coghlan:
>> Even earlier, Victor Stinner wrote:
>>> I consider that the final goal of the whole discussion is to support
>>> something like:
>>>
>>> path = os.path.join(pathlib_path, "str_path", direntry)
>>
>> That's not a *new* problem though, it already exists if you pass in a
>> mix of bytes and str:
>> (...)
>> There's also already a solution (regardless of whether you want bytes
>> or str as the result), which is to explicitly coerce all the arguments
>> to the same type:
>>
>>--> os.path.join(*map(os.fsdecode, ("str", b"bytes")))
>> (...)
>
> I don't understand. What is the point of adding a new __fspath__
> protocol to *implicitly* convert path objects to strings, if you still
> have to use an explicit conversion?
That's the crux of the issue -- some of us think the job of __fspath__
is to simply retrieve the inherent data from the pathy object, *not* to
do any implicit conversions.
> I would really expect that a high-level API like pathlib would solve
> encodings issues for me. IMHO DirEntry entries created by
> os.scandir(bytes) must use os.fsdecode() in their __fspath__ method.
Then let pathlib do it. As a high-level interface I have no issue with
pathlib converting DirEntry bytes objects to str using fsdecode (or
whatever makes sense); os.path.join (and by extension os.fspath and
__fspath__) should do no such thing.
>> os.path.join(*map(os.fsdecode, ("str", b"bytes")))
>
> This code is quite complex for a newbie, don't you think so?
A newbie should be using pathlib. If pathlib is not low-level enough,
then the newbie needs to learn about low-level stuff.
--
~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4