[Python-ideas] PEP 428 - object-oriented filesystem paths
Oscar Benjamin
oscar.j.benjamin at gmail.com
Sun Oct 14 04:16:57 CEST 2012
On 12 October 2012 20:42, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Fri, 12 Oct 2012 12:23:46 -0700
> Ethan Furman <ethan at stoneleaf.us> 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
More information about the Python-ideas
mailing list