[Python-Dev] File system path PEP, part 2 (original) (raw)
Koos Zevenhoven k7hoven at gmail.com
Fri May 13 12:24:54 EDT 2016
- Previous message (by thread): [Python-Dev] File system path PEP, part 2
- Next message (by thread): [Python-Dev] File system path PEP, part 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, May 13, 2016 at 2:00 PM, Steven D'Aprano <steve at pearwood.info> wrote:
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]}.
I would think these have the b suffix because there is no good way to infer which type should be returned. In things like os.path.join or os.path.dirname you pass in the object(s) that determine the return type.
In os.fspath, you pass in an object, whose type (str/bytes) or "underlying path string type" (as returned by fspath()) determines the return type of fspath. I think this is well in line with os.path functions.
-- Koos
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().
- Previous message (by thread): [Python-Dev] File system path PEP, part 2
- Next message (by thread): [Python-Dev] File system path PEP, part 2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]