On Sat, Mar 26, 2016 at 1:56 AM, Chris Angelico <rosuav@gmail.com> wrote:

[...]

If Path objects had universal support in the stdlib *and* significant
support in third-party libraries, they could be the one obvious way to
do pretty much anything involving paths.

True. I suppose many third-party libraries will just work when the stdlib functions they use [like open(...) and os.path.join(...)] have started accepting Path objects. Then, if a third-party library returns a string, one would need to convert it into a path. That is, unless you just directly pass it to open(...) or something so you don't care. How many reasonably things can a library do with paths without just passing them to stdlib functions?

[...]

Should syntax precede or follow extensive usage?

Does anything learned from the evolution of string formatting apply here?

[1] Overloading division doesn't really do anything for you, other
than the way it looks similar to the normal path sep. It's really more
of a concatenation operation, which would normally be + not /.

I agree that joining paths with / is the least interesting feature of pathlib.Path.

Some of this can of course be done with os.path.* too, but here's the list of methods and properties on Path:

['absolute', 'anchor', 'as_posix', 'as_uri', 'chmod', 'cwd', 'drive', 'exists', 'expanduser', 'glob', 'group', 'home', 'is_absolute', 'is_block_device', 'is_char_device', 'is_dir', 'is_fifo', 'is_file', 'is_reserved', 'is_socket', 'is_symlink', 'iterdir', 'joinpath', 'lchmod', 'lstat', 'match', 'mkdir', 'name', 'open', 'owner', 'parent', 'parents', 'parts', 'read_bytes', 'read_text', 'relative_to', 'rename', 'replace', 'resolve', 'rglob', 'rmdir', 'root', 'samefile', 'stat', 'stem', 'suffix', 'suffixes', 'symlink_to', 'touch', 'unlink', 'with_name', 'with_suffix', 'write_bytes', 'write_text']

- Koos