[Python-Dev] When should pathlib stop being provisional?

[Ethan Furman]

On 04/05/2016 10:00 PM, Guido van Rossum wrote:
> On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> [...] we can't do:
>>
>>      app_root = Path(...)
>>      config = app_root/'settings.cfg'
>>      with open(config) as blah:
>>          # whatever
>>
>> It feels like instead of addressing this basic disconnect, the answer has
>> instead been:  add that to pathlib!  Which works great -- until a user or a
>> library gets this path object and tries to use something from os on it.
>
> I agree that asking for config.open() isn't the right answer here
> (even if it happens to work). But in this example, once 3.5.2 is out,
> the solution would be to use open(config.path), and that will also
> work when passing it to a library. Is it still unacceptable then?

On the one hand that is definitely more palatable.

On the other hand it doesn't address having the stdlib itself directly 
support Path.

On the gripping hand this feels reminiscent of the arguments over bytes 
vs unicode, but without any of the "This is why unicode is better!" bits.

Why is pathlib better than plain strings?

- attribute access to different parts such as the dirname, the
   filename, the extension (suffix)
- easy access to on-disk answers such as .exists(), .stat(), .chdir
- easy creation/modification of Path objects

What problem is it solving that makes the pain worth dealing with?

- no idea

This is an especially important point considering the str-derived Path 
libraries already out there that have the same advantages as pathlib, 
but none of the pain.

--
~Ethan~