(original) (raw)
On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
-- On 7 April 2016 at 03:26, Brett Cannon <brett@python.org> wrote:
> 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)
couldn't it be a property?
Method, as long as there's a helper function somewhere
what has the helper function got to do with whether it's a method or attribute (would we call a property an attribute here?)
> Built-in? (name is dependent on #1 if we add one)
os.fspath (alongside os.fsencode and os.fsdecode)
(Putting this in a module low in the dependency stack makes it easy
for other modules to access without pulling in all of pathlib's
dependencies)
Iike that -- though still =0.5 on having one at all -- this is only going to be used by the stdlib and other path-using libraries, not user code -- is that that hard to call obj.\_\_fspath\_\_() ?
> 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)
I thought the whole point off all this is that not any old string can be a path! (whereas any int can be an index). Unless we go with Chris A's suggestion that this be a more generic lossless string protocol, rather than just for paths.
It's worth summarising in a PEP at least for communications purposes -
very easy for folks that don't follow python-dev to miss otherwise.
I'd say add it to the existing pathlib PEP -- along with the extra discussion of why Path does not inherit from str.
-CHB
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov