Le 29/03/2016 14:31, Sven R. Kunze a écrit :
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.
yes. It's a very rare use case. If you create a program that needs to be handling this, you still got the old API.
For the 99% of the rest of the world, you have the modern one. Let's not try to make pathlib handle everything, it's a convenience wrapper, not a silver bullet.
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?
Exactly. pathlib needs improvements, and there is plenty of prior art to make suggestions about this, but if it's a central API, it will be on the spotlight to do so.
Best, Sven _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/