On Dec 28, 2015, at 16:50, Wes Turner <wes.turner@gmail.com> wrote:


On Dec 28, 2015 2:33 PM, "Chris Barker" <chris.barker@noaa.gov> wrote:
>
> On Tue, Dec 22, 2015 at 4:23 PM, Guido van Rossum <guido@python.org> wrote:
>>
>> The two-level iteration forced upon you by os.walk() is indeed often unnecessary -- but handling dirs and files separately usually makes sense,
>
>
> indeed, but not always, so a simple API that allows you to get a flat walk would be nice....

The path.py .walk* APIs work great w/ fnmatch:

https://pythonhosted.org/path.py/api.html#path.Path.walk

https://pythonhosted.org/path.py/api.html#path.Path.walkdirs

https://pythonhosted.org/path.py/api.html#path.Path.walkfiles

The path module has some major differences. First, because it doesn't use scandir or anything else to avoid multiple stat calls, the caching issue doesn't come up. Also, because its Path subclasses str, it doesn't have the same usability issues (you can pass a Path straight to json.loads, for example), although of course that gives it different usability issues (e.g., inherited methods like Path.count are an obvious attractive nuisance). Also, it doesn't handle case sensitivity as automagically. Also, it's definitely the kind of "kitchen sink" design that got PEP 355 rejected (which often makes sense for a third-party lib even when it doesn't for a stdlib module).

So, not everything that makes sense for path will also make sense for pathlib. But it's still worth looking at.