On Fri, 8 Apr 2016 at 08:33 Ethan Furman <et...@stoneleaf.us> wrote: > On 04/08/2016 02:50 AM, Nick Coghlan wrote: > > >> Built-in? (name is dependent on #1 if we add one) > > > > os.fspath (alongside os.fsencode and os.fsdecode) > > I like this better. > > > >> 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) > > > > Makes sense > > What will this do? Return a Path or a str? I don't think we need either. >
When I brought this up it was to return self. > > > >> Expand the C API to have something like PyObject_Path()? > > > > PyUnicode_FromFSPath, perhaps? The return type is well-defined here, > > so it can be done as an alternate constructor, and the C API > > counterparts of os.fsdecode and os.fsencode are PyUnicode functions > > (specifically PyUnicode_DecodeFSDefault and PyUnicode_EncodeFSDefault) > > So this will do the same thing as os.fspath() at the C level, yes? > Yes. > > > > 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. > > Plus my specific API suggestions are pretty different from Ethan's :) > > *sigh* Okay > Chris Angelico and I have been asked by Guido to work together to come up with a proposal after all the discussions are finished and it will most likely be a patch to the pathlib PEP.
_______________________________________________ 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