分享一行 Python 代码 `reduce(add, zip(nums[:n], nums[n:]))` - 来自解决 Leetcode #1470. Shuffle the Array 一题

如果网友点击来是想看这行代码背后运行的逻辑的话，建议先看我“详情”里面给的链接，里面有对这行代码是怎么运行的解释。

然后可以看看评论区，里面有部分没有情绪化的评论有说明这行代码缺陷在哪里。

====

如果网友点进来觉得这行代码写得不好的原因是它不是最优的，那么我同意你的看法，

def solution(nums, n): ans = [] for i in range(n): ans.append(nums[i]) ans.append(nums[n+i]) return ans 

上面这样确实时间更快（甚至可以更快），空间也没有多余。

如果觉得这道题这么解近似最优了，很开心。 我也没话可说，因为我发这个帖子不是来分享这道题的最优解的。

如果预设立场要来贬这行代码，然后又把哪里不好的地方说错了，那么我认为这位网友就是杠精。

关于本帖初衷

“一行”在程序员圈子，对于使用不同语言的 promgrammer 来说确实相对来说属于较敏感词。 不过也确实没想到有部分人反应会这么强烈，为了喷而喷，喷不到点上。

在我看来像函数式编程的语言和支持部分函数式编程的语言，能够合理使用一行的写法就该使用一行的写法。 人家弄一个函数出来，就是为了把定义变量、循环语句、等等重复的工作省掉。

我分享这行代码的出发点是因为几个高阶函数在解决这个问题的应用场景很典型

-- 个人认为是个很好的学习或了解 zip, reduce 的场景，以及涉及到的 functools、和 operator 标准库等。

===

关于算法性能问题

我在做这道题的时候，确实没有考虑 time complexity 和 space complexity；因为一般写法的最优解真的太显而易见。 所以我是从 know higher order function，practice higher order function 的考虑来实现这道题的。

讨论区正如上一个附言所说，有部分人指出这行的代码缺陷，确实有指到真正的点上。 从结论来说，谢谢 @mind3x 的写法更新，time complexity 为 O(n) 的写法可以更新成这样：

def list_extend(l, tuple): l.extend(tuple) return l class Solution: def shuffle(self, nums: List[int], n: int) -> List[int]: return reduce(list_extend, zip(nums[:n], nums[n:]), []) 

如果要写成一行，其实也没有 “强扭”：

def solution(nums, n): return reduce(lambda l, t: (l.append(t), l)[-1], zip(nums[:n], nums[n:], []) 

不过这么写，由于 reduce 多了 initial 参数，理解起来要多花点力气，脱离原本发 functools.reduce(operator.add, zip(nums[:n], nums[n:])) 这一行的初衷。

关于性能分析，为什么是 $O(n^2)$ @gwy15 在评论区已经解释清楚了。

注意一下我在评论区说的

l = [1, 2] l.append(1) 

与

l = [1, 2] l = l + [1] 

的区别。

关于 python 内置类型等方面的使用在算法性能上的分析，这一点有兴趣的朋友可以从 《python 算法教程》一书中了解。其中有说道 list、set、dict 需要注意的地方。

$O(tuple.__add__)$ => $O(n)$ 会造成

reduce(tuple.__add__, <tuple iter>) => $O(reduce)* O(tuple.__add__)$ => $O(n^2)$

的性能问题确实是我在使用这个解法的时候没有去严格分析的。

我了解 tuple + tuple 的问题，不过看了题目 1<=n<=500，我确实没有细想去分析出 $O(n^2)$ 的缺陷。 审题会看一下 n 范围，我想刷过上百道 leetcode 题的朋友应该会懂，这是个刷出来的习惯。因此我个人潜意识里面知道 tuple + tuple 会拖慢速度，但是由于取值范围小，没有去分析是 $O(n)$ 的慢还是 $O(n^2)$ 的慢。

$O(n)$ 写成 $O(n^2)$ 肯定是不好的，正如评论区某个人说的面试这么写是要被挂掉的。

总结

“append”是希望还在学 python 的朋友不要被部分人的节奏带偏了。

本帖初衷是分享一个 python 的 build-in function，functools、operator 标准库，函数式编程方面的东西，因为在 leetcode 的 comment 区解释了一下这一行代码的运行过程，对于对 python 这方面写法还不甚了解的朋友我认为是值得分享的。

本帖原话也没有说这行代码性能 OK，本帖潜意思也没有说这行代码性能 OK，因为敲下键盘之前就知道这么写速度是较慢的；

（再强调一下，针对这道题来说，（各种语言）通用的一般写法写成最优不是很显而易见的吗？这道题就那么写完，有增加什么知识吗？）做到这道题刚好拿来练手 python 的高阶函数和了解函数式编程；是用来 know 和 practice to master 的。

但是另一方面， time complexity 是比 higher order function 更重要的；所以评论区跑代码，改代码指出原贴的一行代码的性能问题是十分有价值的，所以这一行代码也可以作为"在产品中滥用" one-liner 的反例。

附：

虽然说该行代码在产品中是反例。 不过在产品中，遇到这么简单的问题，个人认为应该这么写：

def solution(nums, n): for i in range(n): yield nums[i] yield nums[n+i] 

使用：

for i in solution(the_nums, the_n): ...

or

reformat_nums = list(solution(the_nums, the_n))

如果是按原题意，可能的实际问题是成对取结果，可以直接这么写：

return zip(nums[:n], nums[n:])

python 还有 itertools 库可以提供类似这样问题的实用 function。

leetcode 本来就是用来做练习、掌握知识点用的；总不能说所有 leetcode 题上的“最优解”用在生产环境也是“最优的”吧？

不要被情绪化的、主观偏见的评论带偏了。

总结这么多，是想说，这个贴初衷是分享 python 语言支持部分函数式编程范式的一种类型的写法，以及还有很多实用的 python 标准库。但是有杠精乱喷，所以我强调下不要被杠精带偏节奏，本帖没有说这行解法最好，本帖的初衷也不是杠精口中的那类。

然后有人在评论区指出本帖这行代码的性能问题，这一点我知道会慢，但是确实没有仔细分析；所以对于性能方面讲到重点的地方确实没有错。

你应该看到 reduce(add, zip(nums[:n], nums[n:])) 这样写法的“好懂”之处在哪里；

同时经过本帖的讨论，知道 reduce(add, <tuple iter>) 的性能问题在哪里（reduce(add, <int iter>) 即没有这个性能问题）。另一方面我后面也说了，这个问题本质上不是“一行”的问题，不是代码写成一行性能就会变差，在产品代码中，遇到本帖这类问题，有更好的实现方法（上面“附”以及写出来了）。

而不是因为你（预设立场）反对“python 语言可以一行解决一些问题”觉得不爽，然后过来贬低“一行”代码的写法。

指明代码缺陷在哪里没有问题，我认同这个问题，可以往细节分析。但是预设立场为喷而喷，这种杠精我或不客气回复，或懒得回复。

======

结束语

引用牛人的话作为进一步阐明这个分享帖的出发点，和结束语

“要不这样吧， 如果编程语言里有个地方你弄不明白， 而正好又有个人用了这个功能， 那就开枪把他打死。 这比学习新特性要容易些，然后过不了多久， 那些活下来的程序员就会开始用 0.9.6 版的 Python， 而且他们只需要使用这个版本中易于理解的那一小部分就好了（眨眼） 。”[^1] Tim Peters

[^1]: 给 comp.lang.python Usenet 小组的留言，2002 年 12 月 23 日， “Acrimony in c.l.p”（ https://mail.python.org/pipermail/python-list/2002-December/147293.html ） 。