First of all, thanks for posting, Stephen. I will be responding more thoroughly later, I'll first comment on some points. On Sat, May 14, 2016 at 8:28 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote: [...]
I could argue that this is why Guido was right to remove the restriction that os.fspath return str. The __fspath__ method is part of the "sum category os.path"[1], which is a collection of operations on bytes and on str that parallel each other because they are equivalent representations of filesystem paths. os.fspath therefore is also part of this category. If you want to take the result out of this category and make it str, use os.fsdecode (which is *not* part of this category *because* the codomain is str, not Sum[bytes,str]).
Yes, indeed. This was also the reason why, in the python-dev discussions, I have been arguing for __fspath__ to be able to return both str and bytes *from the beginning*, although I have phrased it quite differently and I think in several different ways. An this is also the reason why, more recently, I've been arguing that os.fspath should *always* allow this too. Before that, I was compromizing towards desires to enforce str, while making the polymorphicity optionally available. I was very happy to learn Guido thought the same, because it meant I could stop arguing for that. If only the path discussion would have had a better signal-to-noise ratio, then this would perhaps have happened faster and many many many man hours would have been saved. -- Koos
Footnotes: [1] The quotes mean "I think I could make this precise but it would be boring. Bear with me, and don't be distracted by the fact that lots of stuff in this 'category' aren't in the os.path *module* -- eg, open() and __fspath__ itself." I hope that the categorical language will be a useful metaphor for those who understand category theory, but really the whole thing is a hand-wavy path to "what implementation would look like".