Make pathlib extensible

I read through some of the previous posts and there was some discussion around how to implement the open functionality. It didn’t seem to reach a solid conclusion? Has there been any decisions or alternative designs considered?

For my random two cents, I personally like the ability to have the open function work for both reading and writing. Professionally, most of my peers use the global open() function and it takes less convincing to get them to use pathlib.open(). I would also argue unless the global function changes the pathlib.open() function should stay with its current interface (and any objects implementing pathlib abcs should uphold this as well).

Interested to here if there has been more thoughts here, currently playing with the backport library for some remote filesystems and quite liking the ability to extend pathlib to other non-local filesystems.

2 Likes