RetroSearch Browse

Tue Apr 12 12:10:55 EDT 2016 · https://mail.python.org/pipermail/python-dev/2016-April/144011.html

On 04/11/2016 02:58 PM, Ethan Furman wrote:
> Sticking points:
> ---------------
>
> Do we allow bytes to be returned from os.fspath()?  If yes, then do we
> allow bytes from __fspath__()?

On 04/11/2016 10:28 PM, Stephen J. Turnbull wrote:
 > In text applications, "bytes as carcinogen" is an apt metaphor.

On 04/12/2016 08:25 AM, Chris Angelico wrote:
 > I would say No and No, on the basis that it's *far* easier to widen
 > their scope in 3.7 than to narrow it.

On 04/11/2016 08:45 PM, Nick Coghlan wrote:
 > I've come around to the point of view that allowing both str and
 > bytes-like objects to pass through unchanged makes sense, with the
 > rationale being the one someone mentioned regarding ease-of-use in
 > os.path.
[...]
> One possible way to address this concern would be to have the
> underlying protocol be bytes/str (since boundary code frequently needs
> to handle the paths-are-bytes assumption in POSIX), but offer an
> "os.fspathname" API that rejected bytes output from os.fspath.

I think this is the way forward:  offer a standard way to get 
paths-as-strings, with an easily supported way of working with 
paths-as-bytes.

This could be with on os.fspathname() & os.fspath() pair of functions, 
or with a single function that has a parameter specifying what to do 
with bytes objects: reject (default), accept, or (maybe) an encoding to 
use to coerce to bytes.

--
~Ethan~

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2016-April/144011.html below:

[Python-Dev] pathlib - current status of discussions