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

[Stephen J. Turnbull]

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".

 > 2. I need a string - use os.fsdecode(p)
 > 3. I need bytes - use os.fsencode(p)
 > 4. 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.<wink/>

 > 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.