Issue 36771: Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames (original) (raw)

Created on 2019-05-01 15:20 by apocalyptech, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 13041 closed python-dev,2019-05-01 15:52
Messages (9)
msg341210 - (view) Author: CJ Kucera (apocalyptech) * Date: 2019-05-01 15:20
It'd be nice to have an option to os.walk which would return DirEntry objects in its return tuple, as opposed to just the string filenames/dirnames. (Or failing that, an alternate function which does so.) The function already uses os.scandir() internally, so the DirEntry objects already exist -- I assume it'd be a pretty easy change. At the moment, if I want to be efficient and use os.scandir() myself, I've got to basically reimplement os.walk(), which seems silly since os.walk is already calling scandir itself.
msg341214 - (view) Author: CJ Kucera (apocalyptech) * Date: 2019-05-01 16:11
I've started up a Github PR for this, btw, though IMO it's not really in a mergeable state yet: 1) I wasn't sure what to do about os.fwalk(), since that *doesn't* already generate DirEntry objects, and this change would introduce a small inconsistency between the two, functionalitywise. 2) Also wasn't sure what to do about unit tests, though I'll ponder that some more once I've got some time later. 3) The actual implementation is pretty trivial, but could perhaps be handled differently. The systems's still processing my CLA signature, as well, so there's that too. :)
msg341223 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2019-05-01 18:23
Hi, I think you have to create a new function and not to modify the current os.walk(), just because you change the type of the returned value. We have to avoid the inconsistency for the caller of os.walk(). is it a list of DirEntry or another list?
msg341226 - (view) Author: CJ Kucera (apocalyptech) * Date: 2019-05-01 18:34
Yeah, I'd wondered that too (re: a separate function) but it seemed like an awful lot of duplicated code. The PR I'd put through just changes the datatypes within the `filenames` and `dirnames` lists... I'd been thinking that'd be sufficient since you wouldn't get that without specifying the optional boolean, but perhaps not.
msg341510 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2019-05-06 14:39
And another solution, you could use the pathlib.Path class for your project. Have a nice day,
msg341513 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2019-05-06 14:45
I would like to have the advices of Serhiy.
msg341516 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-05-06 15:01
I concur with Stéphane. The boolean option for changing the type of the returned value is considered a bad design.
msg341523 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2019-05-06 15:13
Thank you for your contribution but as discussed in this issue, we prefer to have a new function and not a new boolean flag. Here is my suggestions. * Create an other PR where you add a new function * Change the title of this issue. Thank you
msg341524 - (view) Author: CJ Kucera (apocalyptech) * Date: 2019-05-06 15:15
Will do, thanks for the input!
History
Date User Action Args
2022-04-11 14:59:14 admin set github: 80952
2019-05-06 15:15:34 apocalyptech set messages: +
2019-05-06 15:13:28 matrixise set messages: +
2019-05-06 15:01:33 serhiy.storchaka set messages: +
2019-05-06 14:45:06 matrixise set nosy: + serhiy.storchakamessages: +
2019-05-06 14:39:37 matrixise set messages: +
2019-05-01 18:34:49 apocalyptech set messages: +
2019-05-01 18:23:57 matrixise set nosy: + matrixisemessages: +
2019-05-01 16:11:46 apocalyptech set messages: +
2019-05-01 15:52:03 python-dev set keywords: + patchstage: patch reviewpull_requests: + <pull%5Frequest12960>
2019-05-01 15:20:07 apocalyptech create