[Python-ideas] PEP 428 - object-oriented filesystem paths
ethan at stoneleaf.us
Fri Oct 12 21:23:46 CEST 2012
Georg Brandl wrote:
> Am 06.10.2012 20:59, schrieb Ethan Furman:
>> Mike Graham wrote:
>>> On Sat, Oct 6, 2012 at 2:39 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>>>> Georg Brandl wrote:
>>>>> If you inherit from str, you cannot override any of the operations that
>>>>> str already has (i.e. __add__, __getitem__).
>>>> Is this a 3.x thing? My 2.x version of Path overrides many of the str
>>>> methods and works just fine.
>>> This is for theoretical/practical reasons, not technical ones.
>> Ah, you mean you can't give them different semantics. Gotcha.
> Yep. Not much use being able to pass them directly to APIs expecting strings
> if they can't operate on them like any other string :)
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. This would be especially useful for accessing
the functions that haven't been added on to Path yet.
If Path is string based some questions evaporate: '+'? It does what
str does; iterate? Just like str (we can make named methods for the
iterations that we want, such as Path.dirs).
If Path is string based we still get to use '/' to combine them together
(I think that was the preference from the poll... but that could be
wishful thinking on my part. ;) ) Even Path.joinpath would make sense
to differentiate from Path.join (which is really str.join).
Anyway, my two cents worth.
More information about the Python-ideas