On 04/05/2016 10:00 PM, Guido van Rossum wrote:
On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman <et...@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~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
