Documentation of ast.walk misleadingly characterizes its behavior as recursive when it's really iterative

[blhsing]

Documentation

Although the documentation claims that ast.walk generates nodes "in no specified order" and even describes its behavior as "Recursively yield all descendant nodes...", a look at the source code reveals that it really performs a breadth-first traversal by iteratively yielding child nodes in a queue:

def walk(node):
    """
    Recursively yield all descendant nodes in the tree starting at *node*
    (including *node* itself), in no specified order.  This is useful if you
    only want to modify nodes in place and don't care about the context.
    """
    from collections import deque
    todo = deque([node])
    while todo:
        node = todo.popleft()
        todo.extend(iter_child_nodes(node))
        yield node

I thought that maybe this function used to be recursive but found that it has not been modified since its first appearance in CPython 2.6.3.

I think we should at the minimum remove the wording "Recursively" from the description, and optionally:

1. Clarify the actual ordering by changing "in no specified order" to "in breadth-first order".
2. Add a keyword argument such as depth_first that defaults to False such that when it is true, switches to a depth-first traversal that behaves like:

   def dfs_walk(node):
   yield node
   for child in ast.iter_child_nodes(node):
       yield from dfs_walk(child)

[sobolevn]

Clarify the actual ordering by changing "in no specified order" to "in breadth-first order".

This would mean that we would have to commit to this implementation, since it would be promised in the docs.

Is there any real reason why this change is required?

Add a keyword argument such as depth_first that defaults to False such that when it is true

I also think that any alternative function is very easy to implement in 3rd party code. Since ast.walk does nothing special, what cannot be done without it.

I use quite a lot of custom ast iteration in my linters, example: https://github.com/wemake-services/wemake-python-styleguide

[blhsing]

Clarify the actual ordering by changing "in no specified order" to "in breadth-first order".

This would mean that we would have to commit to this implementation, since it would be promised in the docs.

Is there any real reason why this change is required?

No, I don't see a real reason why this change would be required.

But at the same time, I don't see a good reason not to document the existing, very deterministic, behavior, either. BFS is a well known tree traversal order. It isn't like the order of set items that would appear to be fairly random to those who don't delve deep into its implementation.

I can understand if the devs decide that it's best not to commit to any specific ordering though.

Add a keyword argument such as depth_first that defaults to False such that when it is true

I also think that any alternative function is very easy to implement in 3rd party code. Since ast.walk does nothing special, what cannot be done without it.

I use quite a lot of custom ast iteration in my linters, example: https://github.com/wemake-services/wemake-python-styleguide

Yes, I fully agree that any alternative traversal function can be trivially implemented, which is why I listed the change as optional.

The only real request I'm making here is for the wording "Recursively" to be removed to avoid confusion since the word has a specific meaning in programming.