> However, along with that itertools inspired iterator pipeline based
> design, I've also inherited Raymond's preference that particular *use
> cases* start life as recipes in the documentation.

I think it's important to remember where we are coming from. Many people
complain that using os.walk is too cumbersome. Proposing another
cumbersome solution doesn't really help.

So I'm not against walkdir *per se*, but I'm -1 on the idea that walkdir
can eliminate the need for practical functions that anybody can use
*easily*.

> >>> print '\n'.join(sorted(globtree('*.rst', '*.py')))
> ./conf.py
> ./index.rst
> ./py3k_binary_protocols.rst
> ./venv_bootstrap.rst

I think it's rather nice, but it should be available as a stdlib
function rather than a "recipe" in the documentation.

Recipes are really overrated: they aren't tested, they aren't
maintained, they aren't part of a module's docstrings or
(pydoc-generated) contents, it's not obvious what kind of quality you
can expect from them (do they handle all cases correctly), it's not
obvious which Python versions they support. Raymond may like the idea,
but that doesn't make it a "good practice" Python should follow for its
batteries.

> On a somewhat related note, I'd also like to see us start
> concentrating higher level shell utilities in the shutil namespace so
> users don't have to check multiple locations for shell-related
> functionality quite so often (that is, I'd prefer shutil.globtree over
> glob.rglob).

Well, if glob() already lived in shutil, this decision would be a
no-brainer :) Having glob() in the glob module and globtree() in the
shutil module, though, looks a bit weird.
(I agree having a separate module for glob isn't ideal)