[Python-Dev] Pathlib enhancements - acceptable inputs and outputs for fspath and os.fspath() (original) (raw)

Chris Angelico rosuav at gmail.com
Tue Apr 19 23:34:44 EDT 2016

On Wed, Apr 20, 2016 at 1:16 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

Brett Cannon writes:

> Now if you can convince me that the use of bytes paths is very > minimal I doubt that I can do that, because all that Python 2 code is effectively bytes. To the extent that people are just passing it into their bytes-domain code and it works for them, they probably "port" to Python 3 by using bytes for paths. I just don't think bytes usage per se matters to the issue of polymorphism of fspath.

I would prefer to see this kind of code ported to Python 3 by using native strings.

Python 2 code:

import json with open(".config/obs-studio/basic/scenes/Standard.json") as f: data = json.load(f) for scene in data["scene_order"]: print scene["name"]

Python 3 code:

import json with open(".config/obs-studio/basic/scenes/Standard.json") as f: data = json.load(f) for scene in data["scene_order"]: print(scene["name"])

The bulk of path string literals in Python programs will be all-ASCII. Porting to Py3 won't fundamentally change this code, yet suddenly now it's using Unicode strings. In reality, both versions of this example are using text strings. The Py3 version has text in the source code, a stream of Unicode codepoints in the runtime, and then (since I ran this on Linux) encodes that to bytes for the file system. The Py2 version just does that conversion a little earlier: text in the source code, a stream of eight-bit "texty bytes" in the runtime, and those same bytes get given to the fs.

There's no reason to slap a b"..." prefix on every path for Py3. There might be specific situations where you want that, but for the most part, those paths came from human-readable text anyway, so they should stay that way.

ChrisA

More information about the Python-Dev mailing list