Promoting the adoption of pathlib [Was: Working with Path objects: p-strings?]
On 31 March 2016 at 10:46, Sven R. Kunze <srkunze@mail.de> wrote:
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.
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
On 31 March 2016 at 12:55, Koos Zevenhoven <k7hoven@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
On Thu, Mar 31, 2016, at 16:44, Greg Ewing wrote:
If os and io (and open builtin) supported it, I bet that 90% of other modules wouldn't need to do anything to support it. io/open might not even need to explicitly support it. Duck typing = a filename is anything that can be passed to open / some os functions.
On 3/31/2016 13:32, Ethan Furman wrote:
Are path manipulations hard? I have never run into anything that I couldn't solve trivially with os.path. Is this really all this is for?
A better user experience for those users that use pathlib.
In my experience, a rounding error of users.
Much pain on your part until the stdlib fully supports pathlib.Paths.
Considering my last two counterpoints, this is likely to kill any motivation to use the library. If you want to promote pathlib use, really sell pathlib's benefits. the patches to the standard library will come later if people actually want to use it.
On 03/31/2016 10:36 AM, Alexander Walters wrote:
I wouldn't call the contortions I have had to go through to use os.path.* functions "trivial". YMMV.
Two points: 0) I personally have no interest in promoting pathlib -- I wrote my own path library. 1) Part of promoting pathlib is getting the stdlib to use it; otherwise it's a pretty high pain point doing all the string <-> Path conversions oneself. Again, YMMV. I also think creating pathlib was only half the job -- it should have been integrated into the stdlib at the same time. -- ~Ethan~
Le 31/03/2016 19:36, Alexander Walters a écrit :
Slicing is not hard. But we like listing[a:b] better than slice(listing, a, b). Decorating is not hard. But we like @decorator better than func = decorator(func) Try/except is not hard, but we like dict.get('foo', default) better than user KeyError. Path are not hard, but I like better (p / 'foo').absolute() than os.path.realpath(os.path.join(p, 'foo')). I like not having to know if I need to import to look for something in glop, shutils, open or os just for my quick ipython session. Your program is the sum of its parts, and every time you make something a tiny bit clearer, cleaner, easier to use and read, it's a win. Python is fantastic, because it's full of small details making your program simple and easy to write, while clear to read. The FS manipulation API is showing it's age, people are using alternatives from pypi because they like it better, it's been notice and pathlib has been integrated in 3.5. Now pathlib needs improving. But it's here.
On 31 March 2016 at 12:55, Koos Zevenhoven <k7hoven@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
On Thu, Mar 31, 2016, at 16:44, Greg Ewing wrote:
If os and io (and open builtin) supported it, I bet that 90% of other modules wouldn't need to do anything to support it. io/open might not even need to explicitly support it. Duck typing = a filename is anything that can be passed to open / some os functions.
On 3/31/2016 13:32, Ethan Furman wrote:
Are path manipulations hard? I have never run into anything that I couldn't solve trivially with os.path. Is this really all this is for?
A better user experience for those users that use pathlib.
In my experience, a rounding error of users.
Much pain on your part until the stdlib fully supports pathlib.Paths.
Considering my last two counterpoints, this is likely to kill any motivation to use the library. If you want to promote pathlib use, really sell pathlib's benefits. the patches to the standard library will come later if people actually want to use it.
On 03/31/2016 10:36 AM, Alexander Walters wrote:
I wouldn't call the contortions I have had to go through to use os.path.* functions "trivial". YMMV.
Two points: 0) I personally have no interest in promoting pathlib -- I wrote my own path library. 1) Part of promoting pathlib is getting the stdlib to use it; otherwise it's a pretty high pain point doing all the string <-> Path conversions oneself. Again, YMMV. I also think creating pathlib was only half the job -- it should have been integrated into the stdlib at the same time. -- ~Ethan~
Le 31/03/2016 19:36, Alexander Walters a écrit :
Slicing is not hard. But we like listing[a:b] better than slice(listing, a, b). Decorating is not hard. But we like @decorator better than func = decorator(func) Try/except is not hard, but we like dict.get('foo', default) better than user KeyError. Path are not hard, but I like better (p / 'foo').absolute() than os.path.realpath(os.path.join(p, 'foo')). I like not having to know if I need to import to look for something in glop, shutils, open or os just for my quick ipython session. Your program is the sum of its parts, and every time you make something a tiny bit clearer, cleaner, easier to use and read, it's a win. Python is fantastic, because it's full of small details making your program simple and easy to write, while clear to read. The FS manipulation API is showing it's age, people are using alternatives from pypi because they like it better, it's been notice and pathlib has been integrated in 3.5. Now pathlib needs improving. But it's here.
participants (7)
-
Alexander Walters -
Ethan Furman -
Greg Ewing -
Koos Zevenhoven -
Michel Desmoulin -
Paul Moore -
Random832