[Python-Dev] Maybe, just maybe, pathlib doesn't belong.

Sven R. Kunze srkunze at mail.de
Mon Apr 11 17:33:38 EDT 2016


On 11.04.2016 23:05, Random832 wrote:
> On Mon, Apr 11, 2016, at 16:48, Sven R. Kunze wrote:
>> On 11.04.2016 22:33, Alexander Walters wrote:
>>> If there is headway being made, I do not see it.
>> Funny that you brought it up. I was about posting something myself. I
>> cannot agree completely. But starting with a comment from Paul, I
>> realized that pathlib is something different than a string. After doing
>> the research and our issues with pathlib, I found:
>>
>>
>> - pathlib just needs to be improved (see my 5 points)
>> - os[.path] should not tinkered with
> I'm not so sure. Is there any particular reason os.path.join should
> require its arguments to be homogenous, rather than allowing
> os.path.join('a', b'b', Path('c')) to return 'a/b/c'?

Besides the fact, that I don't like mixing types (this was something 
that worried me about the discussion from the beginning), you can 
achieve the same using pathlib alone.

There's no need of it let alone the maintenance and slowdown of these 
implicit conversions.

>> I know that all of those discussions of a new protocol (path->str,
>> __fspath__ etc. etc.) might be rendered worthless by these two
>> statements. But that's my conclusion.
>>
>> "os" and "os.path" are just lower level. "pathlib" is a high-level,
>> convenience library. When using it, I don't want to use "os" or
>> "os.path" anymore. If I still do, "pathlib" needs improving. *Not "os"
>> nor "os.path"*.
> The problem isn't you using os. It's you using other modules that use
> os. or io, shutil, or builtins.open. Or pathlib, if what *you're* using
> is some other path library. Are you content living in a walled garden
> where there is only your code and pathlib, and you never might want to
> pass a Path to some function someone else (who didn't use pathlib)
> wrote?
>
> os is being used as an example because fixing os probably gets you most
> other things (that just pass it through to builtins.open which passes it
> through to os.open) for free.

Hypothetical assumptions meeting implicit type conversions. You might 
prefer those, I don't because of good reason. I was one of those 
starting the discussion around pathlib improvements. I understand now, 
that this is one of its minor issues. And btw. using some "other 
pathlib" is no argument for or against improving "THE pathlib".

The .path attribute will do it from what I can see.


Best,
Sven


More information about the Python-Dev mailing list