[issue36602] Recursive directory list with pathlib.Path.iterdir

[Paul Ganssle]

Paul Ganssle <p.ganssle at gmail.com> added the comment:

> rglob and glob also return a generator.

My mistake, I didn't notice the `sorted` in the `rglob` documentation and thought it was emitting a list.

> By that logic, we should remove `Path.iterdir()` in favour of `Path.glob('*')`.

What *is* the case for why iterdir() is justified when `Path.glob('*')` exists? Is it just discoverability? Is there some efficiency reason to do it?

Of course, removing things (which can break existing code) and failing to add them (which cannot) have two different thresholds for when they can take place, so even if we decide "iterdir() is to glob('*') as iterdir(recursive=True) is to rglob('*')", that doesn't mean that we should remove iterdir() entirely if recursive=True is not added.

> I agree, which is the main reason the current implementation in the pull-request is to not resolve symlinks: users can subclass and implement symlink resolving if they want

I don't see that on the implementation here, but we can discuss this on the PR itself. I do think that skipping *all* symlinks automatically with no option to follow them will be counter-intuitive for people.

> I've never really liked the interface to `walk`, personal preference

I kinda agree about the interface to `walk`, but it is worth noting that as we've seen in this thread, there are a bunch of plausible and slightly different ways to walk a directory: breadth-first or depth-first? following symlinks, following symlinks with cycle detection, or not following symlinks at all? emit the directory itself, or only emit its contents? It's worth taking into account that having two completely different complicated interfaces for recursively walking directories would be a usability challenge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36602>
_______________________________________