[Python-ideas] Making pathlib paths inherit from str

[Joshua Morton]

On Wed, Apr 6, 2016 at 1:28 PM Chris Angelico <rosuav at gmail.com> wrote:


> I'm not sure I entirely understand what's going on here. Your
> rationale is "it should be possible to use a Path as a str", and
> that's supported by your proposal to subclass str; but then you want
> to override a bunch of methods to force users to be aware that a Path
> is *not* a str. Why subclass only to force people to distinguish?

> If you want to make a Path act "just a little bit" like a str, I'd
> expect to go the other way: don't subclass str, and add in a specific
> set of methods to provide str-like functionality. Or am I missing
> something here?

Indeed this was my thought as well. Originally (this was discussed on the
python subreddit to some extent as well), my objection was that a simple
program like say, left_pad.py would break depending on the implementation.
This addresses that issue, but in my opinion creates even deeper problems.

Its not hard to conceive some formatting or pretty printing library that at
some point contains the code

    def concat(user_list: List[String]) -> String:
        return functools.reduce(lambda x, y: x + y, user_list)

where user_list is given from some sort of user input. This change would
lead to some nasty bugs, where this action will throw an error when any two
adjacent args are Paths. What's worse is that type annotations actually
exacerbates this issue since the objects disobey the typechecker.

Java subclasses aren't allowed to just unimplement a parent's methods, they
shouldn't in python either. This argument seems to boil to "well a string
is one valid representation of a path, so a Path is a string" but by that
definition a Path is also a node in a tree, and so we should create a Tree
class and have Path subclass TreeNode, so that we could find out its
children and depth from the root.

There are so many surprising results of a change like this that I can't see
a reason to do this.

-Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160406/80e4a6ea/attachment-0001.html>