Paul Moore writes: > On 16 April 2016 at 12:21, Stephen J. Turnbull <step...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
