On Tue, Oct 9, 2012 at 3:13 PM, Antoine Pitrou solipsis@pitrou.net wrote:
It does suggest a whole new class of verbs though, like "make" or "build".
They are rather vague, though.
Agreed, but what os.path.join actually *does* is rather vague, since it is really "joins the path segments, starting with the last absolute path segment".
I'm mostly playing Devil's Advocate here, but I thought it was a very good point that requesting a Path or PurePath directly is *always* going to be an option. And really, the only time you *need* a PurePath is when you want to construct a non-native path - for native paths you'll always be able to create it, some methods just won't work if it doesn't actually exist on the filesystem.
Using Victor's more complicated example, compare:
open(os.path.join(home, ".config", name + ".conf"))
open(str(Path(home, ".config", name + ".conf"))) open(home.join(".config", name + ".conf"))) open(str(home / ".config" / name + ".conf"))
Path(home, ".config", name + ".conf").open() home.join(".config", name + ".conf").open() (home / ".config" / name + ".conf").open()
One note regarding the extra "str()" calls relative to something like path.py: we get to define the language, so we can get the benefits of implicit conversion without the many downsides by *defining a new conversion method*, such as __fspath__. That may provide an attractive alternative to offering methods that shadow builtin functions:
open(Path(home, ".config", name + ".conf")) open(home.join(".config", name + ".conf")) open(home / ".config" / name + ".conf")
"As easy to use as path.py, without the design compromises imposed by inheriting from str" is a worthwhile goal.
Cheers, Nick.