[Python-ideas] PEP 428 - object-oriented filesystem paths

[Steven D'Aprano]

On 13/10/12 18:41, Nick Coghlan wrote:

> str has a *big* API, and much of it doesn't make any sense in the
> particular case of path objects. In particular, path objects shouldn't
> be iterable, because it isn't clear what iteration should mean: it
> could be path segments, it could be parent paths, or it could be
> directory contents. It definitely *shouldn't* be individual
> characters, but that's what we would get if it inherited from strings.

Ah, I wondered if anyone else had picked up on that. When I read the PEP,
I was concerned about the mental conflict between iteration and indexing
of Path objects: given a Path p the sequence p[0] p[1] p[2] ... does
something completely different from iterating over p directly.

Indexing gives path components; iteration gives children of the path
(like os.walk).

-1 on iteration over the children. Instead, use:

for child in p.walk():
     ...

which has the huge benefit that the walk method can take arguments as
needed, such as the args os.walk takes:

topdown=True, onerror=None, followlinks=False

plus I'd like to see a "filter" argument to filter which children
are (or aren't) seen.


+1 on indexing giving path components, although the side effect of
this is that you automatically get iteration via the sequence protocol.
So be it -- I don't think we should be scared to *choose* an iteration
model, just because there are other potential models. Using indexing
to get path components is useful, slicing gives you sub paths for free,
and if the cost of that is that you can iterate over the path, well,
I'm okay with that:

p = Path('/usr/local/lib/python3.3/glob.py')
list(p)
=> ['/', 'usr', 'local', 'lib', 'python3.3', 'glob.py']

Works for me.



-- 
Steven