[Python-Dev] File system path PEP, part 2 (original) (raw)

Guido van Rossum guido at python.org
Fri May 13 12:21:09 EDT 2016


On Fri, May 13, 2016 at 4:00 AM, Steven D'Aprano <steve at pearwood.info> wrote:

On Thu, May 12, 2016 at 08:53:12PM +0000, Brett Cannon wrote:

> Second draft that takes Guido's comments into consideration. The biggest > change is os.fspath() now returns whatever path.fspath() returns > instead of restricting it to only str. Counter suggestion: - fspath() method may return either bytes or str (no change from the PEP as it stands now); - but os.fspath() will only return str; - and os.fspathb() will only return bytes; - there is no os function that returns "str or bytes, I don't care which". (If you really need that, call fspath directly.) Note that this differs from the already rejected suggestion that there should be two dunder methods, fspath() and fspathb(). Why? (1) Normally, the caller knows whether they want str or bytes. (That's been my experience, you may disagree.) If so, and they call os.fspath() expecting a str, they won't be surprised by it returning bytes. And visa versa for when you expect a bytes path. (2) This behaviour will match that of os.{environ[b],getcwd[b],getenv[b]}. Cons: (3) Polymorphic code that truly doesn't care whether it gets bytes or str will have a slightly less convenient way of getting it, namely by calling fspath() itself, instead of os.fspath().

More cons:

Really, if you want bytes, you should use os.fsencode(); if you want strings, use os.fsencode(); if you want to be polymorphic, use os.fspath() and check the type it returns. I find the case where you'd explicitly want to exclude bytes unusual; Nick already proposed pathlib.Path(os.fspath(x)) for that.

-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160513/5160f1d6/attachment.html>



More information about the Python-Dev mailing list