On 04/06/2016 07:26 PM, Brett Cannon wrote:
> WIth Ethan volunteering to do the work to help make a path protocol a thing --
> and I'm willing to help along with propagating this through the stdlib where I
> think Serhiy might be interested in helping as well -- and a seeming consensus
> this is a good idea, it seems like this proposal has a chance of actually 
> coming
> to fruition.
> 
> Now we need clear details. :) Some open questions are:

Throwing in my 2 bikesheds here, not having read all subthreads:

>  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).

>  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.

>  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.

>  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.

>  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.

Georg


_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to