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~
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