On Sat, Mar 26, 2016 at 4:03 PM, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
[...]
Now with pathlib you don't have to wonder about whether the feature you
are looking for is on "os", "os.path" or "glob" or "open". You don't
have to deal the file opening for such a small script. You don't have to
switch between functions and methods all the time and have to choose
between nested function calls or intermediary variables.


Here we completely agree. I used to do scripting of filesystem-intensive tasks with bash, because it felt more natural, partly because I was doing that before I started using Python for anything. Due to pathlib I now do this stuff in Python, which I of course like better for other reasons. Pretty much everything is there, and nicely auto-completed in editors. The fact that you can do / for joining paths is not necessarily better than a method (which exists too as .joinpath()), but it works and may be easy to remember.
 
The pathlib version is way easier to figure out without knowing the
stdlib by heart, it is one line shorter and one level of indent less.
And you can discover it all from iPython with ".<tab>":

import sys
import pathlib

root = pathlib.Path(sys.argv[1])

files = []
for path in root.glob('*.mp3'):

    name = str(path).replace(path.suffix, '.*')
    files.append(str(path.absolute()))

    for to_remove in root.glob(name):
        if to_remove.suffix != ".mp3":
            to_remove.unlink()

(root / 'playlist.m3u8').write_text('\n'.join(files))


Or even cleaner, and hopefully easier to understand (not tested, sorry):

 import sys
 import pathlib 
 
 root = pathlib.Path(sys.argv[1])
 files = [f.absolute() for f in root.glob("*.mp3")]
 
 for mp3file in files:
     for f in root.glob(mp3file.stem + ".*"):
         if f.suffix != ".mp3":
             f.unlink() # remove non-mp3 version
 
 (root / "playlist.m3u8").write_text("\n".join(files))


Yes, some of the properties could have more logical names like .remove() instead of .unlink(), and there could be even more functionality. Subclassing from str would have obvious benefits, but I'm just not sure whether it's a good idea to inherit things like str.find, str.splitlines, str.title, ... 

So maybe the best thing is not to inherit from str but to make Path quack as much like a str-duck as possible (and vice versa?) without introducing confusing things?

BTW, here's a link to issue #22570 (Better stdlib support for Path objects)
http://www.psf.upfronthosting.co.za/issue22570
 
 - Koos