[Python-ideas] Working with Path objects: p-strings?

[Alexander Walters]

I had to read the traditional way to figure out what you were even 
trying with the other two, so I don't know how 'natural' it is.  As long 
as the traditional way continues to be supported, and this is what 
pathlib is intended to do, I guess I don't care.  I know I'm not going 
to use it.

On 3/26/2016 10:03, Michel Desmoulin wrote:
>
>
> Because it makes a very common task (FS manipulation) much more natural.
>
> This is the same reason people like request over urllib or like
> @decorator over func = decorator(func) or unpacking vs manual item extract.
>
> In a directory of music files, you ave mp3 files you converted to other
> formats. Now you want to remove those conversion. Your task is to find
> all files having the same name as the ones with the mp3 ones, but with a
> different extension, remove them, then list the mp3 absolument path in a
> text file.
>
> This example has baked in a lot of the tasks you do when you use Python
> as a scripting language at the core of you job such as if it's your glue
> language, if you are a tester or for sysadmin tasks. But it helps also
> everybody that once in a file does a one off script.
>
> The traditional approach:
>
> import os
> import glob
> import sys
>
> root = os.path.abspath(sys.argv[1])
>
> playlist = os.path.join(root, 'playlist.m3u8')
>
> with open(playlist, 'w') as f:
>
>      for path in glob.glob(os.path.join(root, '*.mp3')):
>
>          name, ext = os.path.splitext(os.path.basename(path))
>
>          for to_remove in glob.glob(os.path.join(root, name + '.*')):
>              if not to_remove.endswith('mp3'):
>                  os.remove(to_remove)
>
>          f.write(os.path.join(root, path) + "\n")
>
> 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.
>
> 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))
>
> And this true while pathlib is a half backed written lib, since the
> competition (that existed before pathlib and that pathlib failed to
> inspire from), can do even shorter, easier and cleaner:
>
> import sys
> import path
>
> root = path.Path(sys.argv[1]).realpath()
>
> files = []
> for p in root.glob('*.mp3'):
>
>      name = p.namebase + '.*'
>      files.append(p)
>
>      for to_remove in root.glob(name):
>          if to_remove.ext != ".mp3":
>              to_remove.remove()
>
> (root / 'playlist.m3u8').write_lines(files)
>
> Because path.py:
>
> - inherit from str
> - has all the methods from os, not just a few cherry picked
> - has logical names for attributes and methods
> - have more utilities than pathlib or os
>
> So yes, if you do a lot of scripting, this is a must. It's also way
> easier for beginers to grasp.
>
>
>
>
>