[Python-ideas] find-like functionality in pathlib

[Andrew Barnert]

On Dec 28, 2015, at 16:50, Wes Turner <wes.turner at gmail.com> wrote:
> 
> 
> On Dec 28, 2015 2:33 PM, "Chris Barker" <chris.barker at noaa.gov> wrote:
> >
> > On Tue, Dec 22, 2015 at 4:23 PM, Guido van Rossum <guido at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151228/c06086c1/attachment.html>