话说我刚去 chatgpt 问了一个问题，但是他的回答给我感觉是错的（如图），因为我直接拿代码下来跑是错的，然后我去官方文档搜也没搜到这个方法。别的问题我倒觉得还不错。
https://imgse.com/i/zgGH61

问了下 chatgpt 。

可以使用 Linux 的 grep 命令来找到两个文件的并集。

假设文件 a 的内容如下：

1
2
3
4

文件 b 的内容如下：

1,foo,bar
2,hello,world
5,foo,baz
6,hello,world

要找到文件 b 中 id 为文件 a 中的 id 的所有行，可以使用以下命令：


grep -f a b
这将输出文件 b 中与文件 a 中的 id 匹配的行，即：


1,foo,bar
2,hello,world
上面的命令中，-f 选项告诉 grep 使用文件 a 作为搜索模式。您可以使用 -w 选项来仅匹配整个单词，而不是部分单词。

例如，如果文件 a 的内容如下：

hello
world
那么使用 -w 选项的令将输出：

2,hello,world
6,hello,world
但是，如果不使用 -w 选项，命令将输出所有包含文件 a 中的单词的行，即：


1,foo,bar
2,hello,world
5,foo,baz
6,hello,world
因此，要根据需要使用 -w 选项。

@craiiz 再次运行的时候，是因为浏览器的 cache 吗？

之前体验过，感觉慢的很那。

@dayeye2006199 卧槽，这也太贵了吧。

我觉得在国内还是 java，go 的天下。nodejs 和 py 都一般，就没必要互相伤害了。

冷知识：日本 pixiv 跳转外链也会弹。

a | b，不就是 {**a, **b}吗。我也觉得这个没多大意义。
a |= b，是就地修改+返回，比 a.update(b) 多一道可以返回修改后的 dict 。不过也就少些了一句，意义不大。
更多的我感觉应该是为了，让这个能支持 operator 模块，来函数式编程。

至于 import this 的信条，也不看是啥时候说的。就像我自己写的时候想着要写得简洁点，那同事不一定这么想啊，开源社区就是这样，谁都可以说句话，往里面提交些代码，但是吧，py 门槛较低，有些人吧又没那么讲究。要是龟叔独裁了一点，又要被社区的喷。

终究到底，我就希望速度能提上来，这样其他方面我也没怎么要求。

去他的仓库，然后点开 setup.py 或者 requirements.txt 之类的文件，一般里面都有写。
以 requests 为例，https://github.com/psf/requests/blob/master/setup.py#L43
requires = [
'chardet>=3.0.2,<5',
'idna>=2.5,<3',
'urllib3>=1.21.1,<1.27',
'certifi>=2017.4.17'

]

特意挂代理来回答，本来就是上班摸鱼看的，我家里的电脑是有代理，公司的电脑又没弄，也懒得弄代理。难不成我还要远程我家的电脑开个代理来看。上班的电脑也就访问下 https://cdn.v2ex.co ，可以裸进，但是登录不了，也没法加载那些图片资源。

https://paste.ubuntu.com/p/gSvMJRsy7r/ 发错了。。

t/766801#reply6 我简单得写了一个。

@LeeReamond 之前用的 pysnooper 库有 with 块的实现，跟你的需求有点类似，或许可以看看源码改造下。
https://github.com/cool-RR/PySnooper

inspect.getmembers(promotions, inspect.isfunction)

@LeeReamond 行吧，具体阈值我没测清除，不过 cnt 在 15 以内 py 的列表推导快过 np 广播。

上次我测试的时候，发现
n1 = np.arange(cnt, dtype=np.int_)
n2 = list(range(cnt))
n1 + 2
[mem + 2 for mem in n2]
当 cnt 较小的时候，numpy 的广播方式比下面 py 原生循环还慢。之前看文档说，numpy 用的 c 循环，所以比 py 的快。把我整的有点懵。

开了 1w 多进程牛的，整个 multiprocessing.Pool 进程池限制下并行数吧。

在流畅的 python 一书中有提到：
CPython 中的垃圾回收主要依靠引用计数，这容易实现，但是遇到引用循环容易泄露
内存，因此 CPython 2.0 （ 2000 年 10 月发布）实现了分代垃圾回收程序，它能把引用
循环中不可获取的对象销毁。
但是引用计数仍然作为一种基准存在，一旦引用数量归零，就立即销毁对象。这意味
着，在 CPython 中，这样写是安全的（至少目前如此）：
open('test.txt', 'wt', encoding='utf-8').write('1, 2, 3')
这行代码是安全的，因为文件对象的引用数量会在 write 方法返回后归零，Python
在销毁内存中表示文件的对象之前，会立即关闭文件。然而，这行代码在 Jython 或
IronPython 中却不安全，因为它们使用的是宿主运行时（ Java VM 和 .NET CLR ）中的
垃圾回收程序，那些回收程序更复杂，但是不依靠引用计数，而且销毁对象和关闭文
件的时间可能更长。在任何情况下，包括 CPython，最好显式关闭文件；而关闭文件
的最可靠方式是使用 with 语句，它能保证文件一定会被关闭，即使打开文件时抛出
了异常也无妨。

@nicoljiang 问下作者咯