(original) (raw)

On Apr 7, 2016 1:22 AM, "Georg Brandl" <g.brandl@gmx.net> wrote:
\>
\> On 04/06/2016 07:26 PM, Brett Cannon wrote:
\> > 1\. Name: \_\_path\_\_, \_\_fspath\_\_, or something else?
\>
\> \_\_path\_\_ is already taken as a module attribute, so I would avoid it.
\> \_\_fspath\_\_ is fine with me, although the more explicit variants are also
\> ok. It's not like you need to read/write it constantly (that's the goal).

+1

I also think that \_\_ospath\_\_ may be more correct since it is an OS-dependent representation, e.g. slash vs. backslash.

>
\> > 2\. Method or attribute? (changes what kind of one-liner you might use in
\> > libraries, but I think historically all protocols have been methods and the
\> > serialized string representation might be costly to build)
\>
\> An attribute would be somewhat inconsistent with the special-method lookup rules
\> (looked up on the type, not the instance), so a method is probably a better
\> choice.

I was just about to point this out. The deviation by pickle (lookup on instance rather than type) has been a source of pain.

>
\> > 3\. Built-in? (name is dependent on #1 if we add one)
\>
\> I don't think it warrants a builtin. I'd place it as a function in pathlib.

+1

>
\> > 4\. Add the method/attribute to str? (I assume so, much like \_\_index\_\_() is on
\> > int, but I have not seen it explicitly stated so I would rather clarify it)
\>
\> +1.

+1

>
\> > 5\. Expand the C API to have something like PyObject\_Path()?
\>
\> +1 (with \_Py\_ at first) since you're going to need it in a lot of C functions.

+1

-eric