[Python-ideas] Working with Path objects: p-strings?

[Paul Moore]

On 29 March 2016 at 10:43, Michel Desmoulin <desmoulinmichel at gmail.com> wrote:
> +1. Can somebody defend, with practical examples, the imperative to
> refuse to inherit from str ? And weight it against the benefits of it ?

I don't intend to get sucked into the role of "defender of not
inheriting", but one point that should probably be considered is that
on Unix, it is possible to have paths which are *not* valid Python
strings. How would those work in an inherit-from-str environment? I
suspect that using surrogateescape is the answer here, but I don't
know.

Also, has anyone *converted* code from os.path manipulation of strings
to a str-subclass path object like path.py? If you write your code
from scratch intending to use path.py it's probably easier to avoid
objects getting silently downgraded from path to str than if you're
retrofitting a path library to legacy code. That's a consideration
that is more applicable to the standard library than to a 3rd party
module.

But it may be that now is the right time to revisit the choice to not
inherit from str. I don't know, personally. I'm not even sure if a
pathlib.Path that inherited from str is something I'd use more often
than I currently do. For open source work, the need to support Python
2 means I can't use pathlib (without adding the backport as a
dependency). For personal code, it's just a case of mental inertia...

Paul