On Apr 7, 2016 1:22 AM, "Georg Brandl" <g.brandl at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160407/53b1d9a4/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4