Laurie Opperman <laurie_opper...@hotmail.com> added the comment:
> Is the behaviour you're proposing any different from using `Path.rglob('*')`?
By that logic, we should remove `Path.iterdir()` in favour of `Path.glob('*')`.
In addition, having `iterdir` the way it is makes it easy for subclasses to
extend its functionality (for example, one of my `Path` subclasses allows a
callable to be passed to the `iterdir` which can filter paths)
> One thing you may need to worry about here is the fact that symlinks can have
> cycles, so you may need to do some cycle detection to avoid creating the
> dangerous possibility of infinite loops.
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
> There's also the question of whether you want this to be a depth-first or
> breadth-first traversal, and whether you would want both of these to be
> options.
As much as I want to say that I don't see a use-case for breadth-first file
listing (when I list files, I expect the next file provided to be 'next to' the
current file), users currently have no standard-library functionality to
perform breadth-first searches as far as I know: they'd have to implement it
themself or find it in a third-party library
> Slightly related, pathlib.walk was proposed in the past in python-ideas...
I've never really liked the interface to `walk`, personal preference
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36602>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
