将os.walk作为第三项返回生成器对象

Question

在检查os.walk的效率时，我用字符串Hello <number>创建了6,00,000文件(其中数字只是表示目录中文件数量的数字)，例如目录中文件的内容如下：-

File Name | Contents
1.txt     | Hello 1
2.txt     | Hello 2
.
.
600000.txt|Hello 600000

现在，我运行了以下代码：

a= os.walk(os.path.join(os.getcwd(),'too_many_same_type_files')) ## Here, I am just passing the actual path where those 6,00,000 txt files are present
print a.next()

问题是，a.next()花费了太多的时间和内存，因为a.next()将返回的第三项是目录中的文件列表(其中有600000项)。因此，我试图找到一种降低空间复杂性的方法(至少)，方法是让a.next()返回生成器对象作为元组的第三项，而不是文件名列表。

这会是降低空间复杂性的好主意吗？

Answer 1

正如人们已经提到的，一个目录中的60万个文件是个坏主意。一开始，我认为没有办法做到这一点，因为您如何访问文件列表，但事实证明我错了。您可以使用以下步骤来实现您想要的目标：

1. 使用子进程或os.system调用ls或dir (无论您在哪个操作系统上)。将该命令的输出定向到临时文件(例如/tmp/myfiles或其他文件)。在Python中有一个模块可以返回一个新的tmp文件)。
2. 打开该文件，以便用Python读取。
3. 文件对象是可迭代的，并将返回每一行，所以只要您有文件名，就可以了。

Answer 2

这是一个好主意，这就是底层的C API的工作方式！

如果您可以访问雷迪尔，就可以这样做:不幸的是，这并不是Python直接公开的。

这个问题展示了两种方法(都有缺点)。

一种更干净的方法是用C编写一个模块来公开您想要的功能。

Answer 3

os.walk listdir()在引擎盖下检索根目录的内容，然后继续将返回的项列表拆分为dirs和non。

要实现您想要的结果，您需要深入研究，不仅要实现您自己版本的walk()，而且还要实现返回生成器的。请注意，即使这样，您也无法为dirs和文件提供独立的生成器，除非您对修改后的listdir()进行两次单独的调用，并动态地过滤结果。

正如Sven在上面的评论中所建议的那样，最好是解决实际问题(一个dir中的文件太多)，而不是过度设计一个解决方案。