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

[Paul Moore]

On 31 March 2016 at 10:46, Sven R. Kunze <srkunze at mail.de> wrote:
> On 31.03.2016 11:15, Paul Moore wrote:
>>
>> Any suggestions for a better design? It might be nice for someone to
>> write a blog entry or posting somewhere on "how to upgrade your 3rd
>> party library to support pathlib" and one of the harder questions will
>> be "how do I decide whether to return a string or a path?" If we had a
>> good recommendation for this, it might help adoption.
>
> Good point. This discussion has been long already so it might make sense to
> write something down in a concise manner.
>
> I am not sure if I can make a good suggestion here because I am still
> trapped at the point where I need to sort out if a path more like a dict or
> another structured datatype, or if it is more a monolithic object. That will
> be the next blog post topic for me.

I'm only talking here about supporting the *existing* pathlib object.
Discussing alternative path object options doesn't help promote
adoption of the stdlib path object, which is in all honesty the only
thing I'm interested in.

> "how do I decide whether to return a string or a path?"  << very good
> question btw; my initial thought would be; make two functions (maybe the
> same name in two different namespaces), so it's crystal clear what this
> function takes a arguments and what it returns. But I need to think more
> about this.

So, coming at this from the perspective of a library developer:

1. Which interface (the str or the path one) gets the "obvious" name?
Backward compatibility pretty much dictates it'd be the str version.
2. How do I support Python 2.7? And Python 3.3/3.4 (where the ".path"
attribute doesn't exist)?
3. What's my transition plan for the future when I deprecate the str
interface and only support path objects?
4. What will my users have to do if they want to use Path objects in
their code? And how do I minimise their pain in doing so?

So it's a pretty hard issue, to think about adding pathlib support if
you *return* paths. (It's essentially trivial if you only *consume*
paths - just add "patharg = getattr(patharg, 'path', patharg)" at the
top of your APIs, and you're done - apart from testing, documentation,
etc, of course :-))

But without library adoption, *users* bear the pain of adapting
everything to Path objects. And that's a real barrier to adoption.
Maybe once the stdlib uses path objects more consistently (there's a
*lot* of modules that could do with accepting Path or str arguments
equally, and one or two like tempfile that create path names), it will
be easier to argue for wider pathlib support in 3rd party libraries.

Paul