Patching your mails:
On 29.03.2016 14:10, Paul Moore wrote:
However, it does mean that certain use cases are not supported by pathlib. One of the constant issues with core/stdlib development is having to consider how the design affects people with needs you don't personally have. This one's not such a big problem "pathlib doesn't support non-Unicode filenames" is a simple enough to express limitation. But that doesn't help the poor guy debugging an issue with his filesystem-scanning program where a user has a mangled non-Unicode filename somewhere in the bowels of his profile - does he declare that user's situation is unsupported, or does he abandon pathlib in favour of the old os APIs?
Perfect example.
As I said, I've encountered this situation and most likely will encounter it again. We have mostly control over the file names. So, we might be able to fix a problematic file name. The issue you are bringing up (which is perfectly valid) is when you as a developer don't have control over the file name (aka fixing them).
In this regard, I might be pragmatic and say: "let's see what happens". If this is a frequent issue, then this is one of those warts pathlib needs to loose in order to become mainstream.
But why not open another thread with a solution to this issue as has Koos done with p-strings?
(And either way, what's the likelihood of him ever wanting to use pathlib again?)
You mean like myself? As I wanted to use pathlib but found myself writing awkward code with it? (btw. that was not the path->str issue)
That as well needs to be fixed but it's no argument for delaying other improvements, right?
Best, Sven