Re: os.path.walk() lacks 'depth first' option
Tim: Don't get a swelled head or anything ;-), but your generator-based version of walk() is beautiful piece of work. I don't mean the code (although that's clean and readable), but the design. Using a generator is clearly good, having it return (path,names) tuples is a nice way to work, and having it return (path,dirnames,filenames) tuples is inspired. (If you want them lumped together, just add the lists!) Allowing the consumer to modify control the flow by modifying dirnames is very nice. And the fact that it's so simple to code (22 short lines) is a testament to the power of generators. I'm +2 on putting this in immediately and deprecating os.path.walk(). -- Michael Chermside
From: Michael Chermside
Tim:
Don't get a swelled head or anything ;-), but your generator-based version of walk() is beautiful piece of work. I don't mean the code (although that's clean and readable), but the design. Using a generator is clearly good, having it return (path,names) tuples is a nice way to work, and having it return (path,dirnames,filenames) tuples is inspired. (If you want them lumped together, just add the lists!) Allowing the consumer to modify control the flow by modifying dirnames is very nice. And the fact that it's so simple to code (22 short lines) is a testament to the power of generators.
I'm +2 on putting this in immediately and deprecating os.path.walk().
Agreed. How about naming it os.walk()? I think it's not OS specific -- all the OS specific stuff is part of os.path. So we only need one implementation. --Guido van Rossum (home page: http://www.python.org/~guido/)
I'm +2 on putting this in immediately and deprecating os.path.walk().
Agreed. How about naming it os.walk()? I think it's not OS specific -- all the OS specific stuff is part of os.path. So we only need one implementation.
Double check on SF. Someone had posted a patch for this and Martin v. Löwis had some reasons for rejecting it or something else that should have been done at the same time. Raymond Hettinger ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################
[Guido]
Agreed. How about naming it os.walk()? I think it's not OS specific -- all the OS specific stuff is part of os.path. So we only need one implementation.
I've checked this in, modified to treat symlinks the same way os.path.walk() treated them, and with docs and test cases. It wasn't my intent to cut off people who want fancier stuff, but available time is finite, and at least now they can demonstrate their sincerity by supplying code, doc, and test suite patches <wink>.
Tim Peters said:
I've checked this in, modified to treat symlinks the same way os.path.walk() treated them, and with docs and test cases. It wasn't my intent to cut off people who want fancier stuff, but available time is finite, and at least now they can demonstrate their sincerity by supplying code, doc, and test suite patches <wink>.
For the record - the version I posted (with breadth-first as an option) wasn't reliable (it runs out of stack space on reasonable directory structures). Andrew -- http://www.acooke.org/andrew
[andrew cooke]
For the record - the version I posted (with breadth-first as an option) wasn't reliable (it runs out of stack space on reasonable directory structures).
Apart from that, did you have a use case for breadth-first directory traversal? Because it's clumsier, you usually find BFS only used on search trees that are too deep/expensive to traverse exhaustively (e.g., a tree of chess moves), or that have infinite paths (so that DFS can't terminate even in theory). Directory trees aren't usually <wink> of that nature.
On Thursday 24 April 2003 12:50 pm, Guido van Rossum wrote:
Agreed. How about naming it os.walk()? I think it's not OS specific -- all the OS specific stuff is part of os.path. So we only need one implementation.
It's a minor quibble to be sure, but os.walk doesn't really describe what exactly it's doing. I'd suggest os.pathwalk, but that'd be too error-prone, being os.path.walk without a dot. Perhaps os.pathwalker? Just a (likely ill-informed :)) opinion :) Jeremy
On 25 April 2003, Jeremy Fincher said:
It's a minor quibble to be sure, but os.walk doesn't really describe what exactly it's doing. I'd suggest os.pathwalk, but that'd be too error-prone, being os.path.walk without a dot. Perhaps os.pathwalker?
os.walktree? os.walkdirs? os.walkpath?
(On reflection, the latter two are pretty dumb. walktree is the right
name, undoubtedly. ;-)
Greg
--
Greg Ward
[Jeremy Fincher]
It's a minor quibble to be sure, but os.walk doesn't really describe what exactly it's doing. I'd suggest os.pathwalk, but that'd be too error-prone, being os.path.walk without a dot. Perhaps os.pathwalker?
[Greg Ward]
os.walktree? os.walkdirs? os.walkpath?
(On reflection, the latter two are pretty dumb. walktree is the right name, undoubtedly. ;-)
I don't expect any short name to describe exactly what a thing does, and don't worry about it. math.sin() isn't about lust in your heart, or math.tan() about practicing safe sunning either. Guido has his own inscrutable criteria for picking names. Mine is whether, *after* I know what a thing does, it's hard to forget what the name means. "walk" passed that test for me, and better than Python or Java did <wink>.
Jeremy Fincher
It's a minor quibble to be sure, but os.walk doesn't really describe what exactly it's doing.
How about os.walkdir (by analogy with os.listdir). Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
[Greg Ewing]
How about os.walkdir (by analogy with os.listdir).
[Tim]
I'm -0 on bothering to change the name, but, if we have to, I'm +1 on walkdir (for the reason Greg gives there).
I'm -1 om changing the name. os.walk() it is. Short-n-sweet, --Guido van Rossum (home page: http://www.python.org/~guido/)
On 29 April 2003, Guido van Rossum said:
I'm -1 om changing the name. os.walk() it is.
Sheesh, it's like my undeniably brilliant suggestion of os.walktree()
disappeared into thin air. Ah well, back to wasting my vast talents
elsewhere... ;->
Greg
--
Greg Ward
On 29 April 2003, Guido van Rossum said:
I'm -1 om changing the name. os.walk() it is.
Sheesh, it's like my undeniably brilliant suggestion of os.walktree() disappeared into thin air. Ah well, back to wasting my vast talents elsewhere... ;->
Greg
Sorry, I didn't see your suggestion until after I'd released 2.3b1. The difference is not significant enough to rename things again after the beta release. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Michael Chermside]
Don't get a swelled head or anything ;-), but your generator-based version of walk() is beautiful piece of work. I don't mean the code (although that's clean and readable), but the design. ...
Thanks for the nudge! If you hadn't reminded us, I bet this would have been forgotten. (I would have replied earlier, except my head got so heavy it took this look to peel my lips off the floor.)
participants (10)
-
andrew cooke -
Greg Ewing -
Greg Ward -
Guido van Rossum -
Jeremy Fincher -
Michael Chermside -
Raymond Hettinger -
Tim Peters -
Tim Peters -
Tim Peters