On 12 October 2012 20:42, Antoine Pitrou
On Fri, 12 Oct 2012 12:23:46 -0700 Ethan Furman
wrote: Which is why I would like to see Path based on str, despite Guido's misgivings. (Yes, I know I'm probably tilting at windmills here...)
If Path is string based we get backwards compatibility with all the os and third-party tools that expect and use strings; this would allow a gentle migration to using them, as opposed to the all-or-nothing if Path is a completely new type.
It is not all-or-nothing since you can just call str() and it will work fine with both strings and paths.
I assumed that part of the proposal for including a new Path class was that it would (perhaps eventually rather than immediately) be directly supported by all of the standard Python APIs that expect strings-representing-paths. I apologise if I have missed something but is there some reason why it would be bad for e.g. open() to accept Path instances as they are? I think it's reasonable to require that e.g. os.open() should only accept a str, but standard open()? Oscar