[Python-ideas] Working with Path objects: p-strings?

[Michel Desmoulin]

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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/