在 `clojure.core/partition` 中疑似存在bug

Question

2个问题
- clojure.core/partition的文档字符串没有清楚说明“最后一个分块”的含义。
- partition的行为很奇怪，我认为它有bug。

请看看这个

(partition 3 1 [:a :b :c] (range 5))

; actual behavior
; => ((0 1 2) (1 2 3) (2 3 4) (3 4 :a))

; expected behavior, option 1
; => ((0 1 2) (1 2 3) (2 3 4))

; expected behavior, option 2
; => ((0 1 2) (1 2 3) (2 3 4) (3 4 :a) (4 :a :b))

我期望“最后一个分块”定义为

包含来自输入集合（不是填充集合）但不包含在任何前一个分块中的元素。

这与上面的选项1是一致的。

Answer 1

选项2可以排除，因为不管“最后一个分块”意味着什么，只能有一个“最后一个分块”，并且只有它可以来自填充集合。

文档字符串说“如果提供了填充集合且填充元素不足，则返回包含少于n个项的分块”，因此选项1也可以排除。

如何澄清文档字符串？

Comments

零填充元素数量小于n个。我认为选项1没有什么问题。

我更新了问题，包括我对“最后一个分区”的建议定义。

Answer 2

partition会分割全部的N个元素。如果不能制作完整的分区，您就结束了。如果提供填充集合，它将使用该集合完成所有不能制作完整分区的第一个分区（这将是对最后一个分区的填充）。

• 在没有填充集合的情况下，选项1是预期的行为（在不能制作完整分区时停止），但这里有填充集合
• 选项2将会制作多（<N）个分区，所以不合适

我理解#2作为可能的解释（尤其是与partition-all行为相同的情况相比），但我认为更改当前行为可能会对现有用户产生破坏性变化。

Comments

我强烈感觉到我的问题被误解了。

当我尝试调用`partition`函数时（为`step`参数提供了一个自定义值，即与`n`不同的值），这里存在的问题。到目前为止，还没有人提到关于`step`参数的回答。

---

我不是Clojure核心团队的成员，所以不能代表他们发言，但我可以说他们确实重视核心函数的行为向后兼容。鉴于`partition`当前的行为已经如此至少有10年了，他们可能会不愿意改变其行为，以免现有的任何工作代码依赖于它，包括其所有的细节。

如果这种情况成立，那么核心团队更有可能考虑修改文档以澄清现有行为，而不是改变行为。

还有一些网站，如https://docs.clojure.org/clojure.core/partition，允许用户贡献核心函数行为的示例，并对其进行注释解释，这比大多数Clojure核心函数在其文档字符串中包含的示例更为详细。

---

`step`参数与描述的行为无关：(partition n coll)相当于(partition n n coll)，即带有n步长的分区，因此它始终有一个步长值，这仅决定了coll Skip之前在Starting next partition多少元素。Alex描述的行为不会受到步长值的影响。

只有当最后生成的分区不包含n个项目时，pad集合才重要。

dev=> (partition 3 3 [:a :b :c] (range 5))

((0 1 2) (3 4 :a))

dev=> (partition 3 3 (range 5))

((0 1 2))

dev=> (partition 3 2 [:a :b :c] (range 5))

((0 1 2) (2 3 4) (4 :a :b))

dev=> (partition 3 2 (range 5))

((0 1 2) (2 3 4))

dev=> (partition 3 1 [:a :b :c] (range 5))

((0 1 2) (1 2 3) (2 3 4) (3 4 :a))

dev=> (partition 3 1 (range 5))

((0 1 2) (1 2 3) (2 3 4))