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

[Koos Zevenhoven]

On Thu, Mar 31, 2016 at 1:59 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 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

I agree about pretty much everything here. My upcoming proposal
addresses most of this, but I will add more words about writing code
that also works in older Python versions. Thanks!

- Koos