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

[Ethan Furman]

On 03/29/2016 03:36 AM, Paul Moore wrote:
> On 29 March 2016 at 10:43, Michel Desmoulin  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 cannot.  Pathlib seems far too complicated to me. (And this coming 
from the guy whose antipathy [1] path library has both bytes and unicode 
inheritance and supports 2.7 and 3.3+ in the same code base.)

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

With antipathy's Path you get either a bPath if the incoming object was 
from bytes (str in 2.x) or a uPath if it was str (unicode in 2.x).  The 
only problem I have ever hit is with older libraries that were doing 
type-checks instead of isinstance-checks on their incoming arguments.

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

If I have to do any other work with the code, then I convert the os.path 
portions to Path first.  It just makes it so much clearer.

> But it may be that now is the right time to revisit the choice to not
> inherit from str.

Is it still marked provisional?  The pain of using it with any other 
portion of the stdlib that uses paths makes it a non-starter for me.

--
~Ethan~


[1] https://pypi.python.org/pypi/antipathy/