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
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.