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

Stephen J. Turnbull stephen at xemacs.org
Sat Apr 16 09:46:02 EDT 2016

Paul Moore writes:

On 16 April 2016 at 12:21, Stephen J. Turnbull <stephen at xemacs.org> wrote:

OK, you win, fspath needs to be polymorphic.

But you've just shifted me to -1 on "os.fspath": it's an attractive nuisance. EIBTI, applications and high-level library functions should use os.fsdecode or os.fsencode.

I presume your expectation is that os.fsencode/os.fsdecode will work with objects supporting the fspath protocol?

Yes, I've suggested that before, and I think it's TOOWTDI, rather than insisting on a os.fspath intervening, even if os.fspath is included after all.

So the question for me is, if I'm writing a function that takes a path argument p:

  1. I just want to pass the argument on to other functions - just do so, stdlib functions will work fine.

I think this is a bad idea unless you need polymorphism, but OK, it's "consenting adults".

  1. I need a string - use os.fsdecode(p)
  2. I need bytes - use os.fsencode(p)
  3. I need a guaranteed pathlib.Path object so that I can use Path methods - convert via pathlib.Path(os.fsdecode(p))

LGTM. Applications or user toolkits could provide a derived IFeelLuckyPath(Path) for symmetry with the os functions.

I guess there's the possibility that you want to deliberately reject bytes-like paths,

I wouldn't put it that way. I think more likely is the possibility that you want to restrict yourself to a particular type, as all your code is written in terms of that type and expects that type. Note that Nick's example shows that in both the bytes domain and the text domain you can easily end up with a filelike.name of the wrong type.

and it's not immediately obvious how you'd do that without os.fspath or using the fspath protocol directly, but I'm not sure what anyone gains by doing so (maybe the chance to fail early? but doesn't using fsdecode mean I never need to fail at all?)

Well, wouldn't you like to raise there if your dataflow spec says only one type should ever be observed?

The reasons that I wouldn't bother are that (1) I suspect it's going to be very rare to see bytes in a text application, and (2) in bytes- oriented code I would be fairly likely to either specify literals as str (a bug, but nobody would ever notice) or importing them from an .ini or other text source (which might very well be in a non- filesystem encoding in my environment!) In either case it's probably the filename I want but specified in the wrong form.

More information about the Python-Dev mailing list