On Thu, May 12, 2016 at 07:22:25PM +0200, Sjoerd Job Postmus wrote: > The whole point of adding `os.fspath` is to make it easier to use Path > objects. This is in an effort to gain greater adoption of pathlib in > libraries. Now, this is an excellent idea. > > However, if it were to reject bytes, that would mean that when libraries > start to use pathlib, it would suddenly become harder for people that > actually need bytes-support to use pathlib. I'm not sure how it would be *harder*. Currently, if you need bytes paths, you can't use pathlib. That won't change, so it will be exactly as hard as it is now. > Now, the claim 'if you need bytes, you should not be using pathlib` is a > reasonable one. But what if I need bytes *and* a specific library (say, > image handling, or a web framework, or ...). It's not up to me if that > library uses pathlib or plain old os.path.join. I feel this is Not Our Problem. Surely the stdlib cannot be held responsible for all the poor decisions made by third-party libraries? If a library hard-codes "\\" as their directory separator, because everyone uses Windows, you'd simply say "this library is not very good for my use-case". Likewise if it rejects bytes paths, then: - perhaps that library is not fit for your purpose; - perhaps you can use it, but with the limitation that you can no longer support all paths, but only the ones which can be accessed via a string path; - perhaps you can build a compatibility layer that lets you use both bytes and the library. I don't doubt that all three options are unpleasant, but I don't see how they are the fault of this PEP. This PEP supports Path-Like objects that return bytes paths. Its up to library authors to support bytes paths, or not, as they see fit. -- Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4