dirwalk.py generator version of os.path.walk
Jim Dennis
jimd at vega.starshine.org
Thu Feb 28 17:41:11 EST 2002
More information about the Python-list mailing list
Thu Feb 28 17:41:11 EST 2002
- Previous message (by thread): dirwalk.py generator version of os.path.walk
- Next message (by thread): dirwalk.py generator version of os.path.walk
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
In article <just-BED145.11365928022002 at news1.xs4all.nl>, Just van Rossum wrote: >In article <a5kv49$ae8$2 at news.idiom.com>, > jimd at vega.starshine.org (Jim Dennis) wrote: >>> I wrote a different implementation of this general concept at: >>> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/105873 >>> You don't really need to keep a stack of directories and push/pop >>> things, because with generators you can recurse instead. >>> Tom BTW: Tom, I did come across your version in the ASPN a day or so after I wrote mine. I agree it looks cleaner and simpler. I might still use a list (FIFO or stack) and while loop instead of the recursion. (see below). >> But recursion is likely to cost more. The only state I need >> to keep is my current "todo" list of directories. A recursion >> would store functional state (unless Python supported tail-end >> recursion). So the append/pop (total cost, 3 lines of code) >> seems like the lightest weight way to do this. > Why don't you try it out? Setting up a generator is as expensive as > calling a function, but resuming or yielding a generator is _very_ cheap. > I personally find the recursive version clearer. > Just I guess I'm just wary of recursion, particularly when I've read that Python doesn't support tail-end recursion. However, I agree that a good test is worth infinitely more than any amount of theoretical speculation. I've read that there's some sort of profiling module for Python; how would I profile each of these approaches in terms of footprint CPU utilization and wall-clock time? As I say, I'm still concerned that the generator will have lots of stack frame overhead in recursion while the interative approach just incurs the size of the list. I'm considering playing with my dirwalk() a bit more (possibly adding additional options to it, or implementing it as a class and writing a set of Decorators to add some of the features that I mentioned in my OP. I suspect I need to design it as a hybrid; options that affect the depth and traversal (i.e. not crossing mount points, setting max depth, etc) should probably be added in, things that affect the yield()'d results (anything returned by stat(), filename or regex patterns, contents scans, etc) should probably be done in Decorators). I'm just trying to learn how to be a "real programmer" so this is mostly for personal edification. However, it would be nice if I created a useful Python module which provided all of the power for Python that the "find" command provides to the shell. (Of course we already *can* do most of that with os.path.walk, and we could use popen() on a find command, or we could use either of these dirwalk() generators and do our own stats, etc. However, I'd like to write something that makes it a bit easier and more concise.
- Previous message (by thread): dirwalk.py generator version of os.path.walk
- Next message (by thread): dirwalk.py generator version of os.path.walk
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list