[Python-ideas] PEP 428 - object-oriented filesystem paths

[Ethan Furman]

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.