I think if you're doing stuff more complicated than just a straight read it's probably okay, but most articles are doing straight reads. I mean, you're opening a raw zip in there
pathlib.Path used to be a context manager which then would flag the Path as closed after use. Even with this closed flag being removed for a while now, I still have a bit of an ick about it.
tbh as someone who uses python for quick scripts much alike shell scripts, pathlib feels more like quite a heavy oop wrapper just to do path manipulation, considering the other stuff (string manipulation, subprocesses, i.e.) that i do – are there advantages for using pathlib itself?
You can do `Path('path').read_text()`, which is easier to copypaste around. Also if you need the file suffix it's just `.suffix` instead of `os.path.splitext(path)[1]`. It's just a lot more convenient IMO
i mean that's what imo doesn't feel right – why can Path objects do file operations? are we expecting Path objects to always correspond to a file on disk? (no.) then why?
extensions do make sense as a property, though imo it still feels strange to have heavyweight objects just for a bytestring.
Comments
with open('path') as f:
x = https://f.read()
You can do `Path('path').read_text()`, which is easier to copypaste around. Also if you need the file suffix it's just `.suffix` instead of `os.path.splitext(path)[1]`. It's just a lot more convenient IMO
extensions do make sense as a property, though imo it still feels strange to have heavyweight objects just for a bytestring.