[Python-ideas] PEP 428: poll about the joining syntax

[Nick Coghlan]

On Tue, Oct 9, 2012 at 3:13 PM, Antoine Pitrou <solipsis at 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.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia