其实还可以这么写，如果不嫌没必要的话：
from itertools import chain
from pathlib import Path

def chain_method_result_iters(op):
def __call__(self, *args):
invoke = lambda it: op(self, it)
return chain.from_iterable( map(invoke, args) )
return __call__
merge_glob = chain_method_result_iters(Path.glob)

list(merge_glob(Path("/tmp"), "*.xpi", "*.1000")) 结果同上不用高阶函数的版本
不过就代码复用比可读性来看，这么做意义不大

看来 Python 的 core devs 还是一群文艺青年，我还以为导入这个模块可以提供 this 字面名呢

嘛 我的意思是第四行

Complex is better than complicated.
是啊，可是 self 哪里比 implicit this （实际上有点像作用域策略） 更 *不* complicated 的了？

可是你这 self 是哪来的呢 是谁传进来的呢

况且红姐用的实现语言就是 Python，能不能别还没确定就开批了……

建议参考了解 bound method 和 function 的区别

implicit 出的啊 面向对象固有的啊，constructor call 的 "fruit"

可是你还是复制粘贴来的代码啊

以前 C 的时候人们就喜欢用 SomeClass_someMethod(struct SomeClass*, int arg1) 这种方式来实现“面向对象”

好好好，我服了，我是复制粘贴的丧门犬 😩

我真的服了

一会儿python不太面向对象，一会儿比python懂编程，一会儿复制粘贴一份代码过来然后说这是xx写的你也配批评？

那你以后是不是要开始给我戴上「杠精」「不懂Python」的帽子了

对的

唉 不对线了

但是我同意你的关于 str.join(iter) 的说法

这个真的是历史遗留 看下来是真的不美观

我是真的服了，对不起，其实我在这继续下去也是浪费时间嘛……

别的说法我就不苟同了