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

[Sven R. Kunze]

On 29.03.2016 12:36, Paul Moore wrote:
> 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.

I don't know how other system developers are working in this field but 
that might be something serious I encounter from time to time.

As a developer and API designer, one has two options (off the top of my 
head):

1) design and code with Unicode/UTF-8 as file names
2) deal with arbitrary bytes in file names

I like 1) more because it gives me the ability to extract useful 
data/text from paths, which as far as I can tell is quite some usecase.
2) is more like a black box variant to me, but then operations like "/" 
or "+" or "suffix" etc. have far less meaning (at least to me).

> How would those work in an inherit-from-str environment? I
> suspect that using surrogateescape is the answer here, but I don't
> know.

Could you explain what this means?

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

Good point. It's quite problematic to convert a large system at once, so 
a transition is necessary. Maybe, that is a reason why more people want 
path->str.

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

It's only one of its warts. In order to get a greater mass to make the 
transition, most of these issues needs to be removed.

Quite recently, there has been a discussion to add something to pathlib 
(I can't remember now) but it failed to get through because of "purity 
over practicability". A wasted chance IIRC. That thing was exactly what 
the Zen warns about.

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

Adding the dependency works for me.


Best,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160329/6088f859/attachment.html>