onerror useful? We don’t have anything like that in pathlib currently.
It is only used in walk — even in os. Might be either a strange design decision or a use case unique to walk.
Unlike most os functions, walk is intended to be error-free, which, I think, is why it requires such an argument.
The difficulty is that walk does multiple operations. For opening a file, returning data or an error is fine. But for a tree traverse, there can be partial success.
It might be ok to ignore the fact that you can’t enter /proc when looking for your PDF and just continue looking. It might not be ok to ignore errors when you’re trying to correct some permissions in a tree. There’s no way to make a default that works well for both use cases.
Okay. So to summarize:
- Top down and bottom up modes are not simple inverses of each other.
- Onerror mode is quite necessary for the (partial correctness) purposes of walk.
- Its return type (arguably) makes sense and is not that easy to simplify
- The majority of pathlib functions return Paths, not direntries
- Only about 3-5 lines of os.walk will need to be changed if we decide to follow their exact implementation but with paths
So it feels to me that an easy solution is not gonna cut it. We either go with the wrapper (which is bad because it’s slow) or with duplicating most of the os.walk code (which is bad because of code duplication, but pretty fast, and tests can be taken straight from os with minimal changes).
There is a potential third option: modify
os.walk itself to add some parameters to do the required changes. It already immediately defers to a private
os._walk(), so that could be given some parameters. Downside is that would slow
os.walk(), but doing a few boolean/none checks hopefully isn’t significant.
Well, we don’t exactly need any new parameters. We could add ‘use_pathlib’ but no one has done that before so it seems bizarre.