[Python-ideas] Promoting the adoption of pathlib [Was: Working with Path objects: p-strings?]

[Paul Moore]

On 31 March 2016 at 12:55, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> My upcoming proposal addresses most of this

I'll wait to see what you propose, but understand that I'm not talking
in this thread about changing pathlib significantly (certainly not in
terms of making Path objects "act like" strings).

I'm personally not interested in considering any model other than str
for the textual representation of paths, and pathlib.Path for the rich
path object. I'm interested in trying to promote the existing
approach, not in changing it before it's had a chance to prove itself.

I no longer see the idea of pathlib.Path subclassing (or otherwise
acting transparently as) str as an important goal, as it only really
affects passing paths to libraries that expect str, which is the
direction that's a trivial library change to fix (and I think we *do*
need to encourage libraries to make changes to support pathlib, rather
than letting them ignore it).

In fact, my first proposal would be to encourage people to raise
issues against their favourite 3rd party libraries asking for pathlib
support for arguments representing paths. Something like the following
should make it clear to the project that it's not a big issue to do
so:

    In function xxx, please support passing a pathlib.Path for
argument bar. This can be done
    simply by adding a line
        bar = getattr(bar, 'path', bar)
    at the top of the function, which will support pathlib from Python
3.5.2 and 3.4.5 onwards.
    I do not think that there is any need to support older versions of pathlib.

Hmm, I've just noticed that the ".path" attribute is new in 3.5.2,
which is not released yet. Maybe we should wait until it is before
promoting this approach :-) I do still prefer this approach, though,
as it doesn't require importing pathlib, and it doesn't accept other
types of object the way str(patharg) does.

Paul