I am suggesting to add max_depth argument to os.walk. I think this is very useful for two cases. The trivial one is when someone wants to walk on a directory tree up to specific depth. The second one is when you follow symlinks and wish to avoid infinite loop.

The patch add the max_depth both to os.walk and os.fwalk.

Wouldn't the "symlink infinite loop" case be better handled by making it track where it's already been? This can be done by inode and dev number on Unix; I'm not sure what equivalent exists on Windows (though symlinks are uncommon on Windows) but you could fall back on realpath.

os.walk() allows more flexible control.

    for root, dirs, files in os.walk(top):
        if is_too_deep(root):
            dirs.clear()
            continue
        ...

You can even walk up to different depth on different parts of the tree. You can limit walking not by the directory depth, but by the length of the path, or the number of links in the path, or what-you-need. Adding separate parameters for all this particular cases is not practical.

I think there is a little need in this feature.

I am not sure about the wide use of this feature but I do think this is a nice feature to add to os.walk. I can see how you can implement is_too_deep by counting the number of separators in the path. However I don't think it is trivial to do that. In addition doing the same when topdown is False will not work.
As for the other limitations you suggested I think they are less trivial then limiting the recursion depth.

As for the "symlink infinite loop" I agree that it will be better to do that by tracking the paths we have already visited but avoiding infinite loop is just a bonus that you get from this feature.

I proposed a new function called lwalk(level walk) that recurses only to a certain level of depth: http://bugs.python.org/issue30942
It is implemented in os.py and calls os.walk, but making sure it recurses only to a selected level of depth.
If it is accepted I could send a Pull Request with the lwalk function implemented in os.py.

> I think there is a little need in this feature.

I concur with Serhiy and think we're better-off without this proposal.
Marking this as closed.