在 `clojure.core/partition` 中疑似存在错误

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没有问题。

我已经更新了我的问题，包括我对"last partition"的建议定义。

Answer 2

partition会对N个元素进行完全划分。如果不能划分一个完整的分区，那么就结束了。如果你提供填充colll，它将使用该填充colll来补充第一次划分时无法划分的分区（这将是最后的分区）。

• 当没有填充colll时，选项1是期望的行为（在有完整的分区划ibrn定刻时停止），但是这里有一个填充colll
• 选项2会创建多个小于（code><N

我可以理解#2作为一个可能的解释（特别是与其他partition-all行为相比较），但我认为改变当前行为可能会对现有用户造成潜在的重大更改。

Comments

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

当用自定义的`step`参数（一个不同于`n`的值）调用`partition`函数时，存在我试图指出的这个问题。到目前为止，还没有答案提到`step`参数。

---

我并不是Clojure核心团队的成员，所以不能代表他们发言，但可以说他们肯定重视核心函数的行为与向后兼容性。鉴于`partition`当前的行为方式已经保持了至少10年，他们可能不愿意更改其行为，以免任何依赖于它的代码出现问题。

如果情况如此，那么核心团队更有可能考虑更改文档以说明现有行为，而不是更改行为。

还有像https://docs.clojure.org/clojure.core/partition这样的网站，允许社区用户贡献核心函数行为的示例，并提供解释性注释，比大多数Clojure核心函数在其doc字符串中可能包含的示例更为丰富。

---

`step`参数与描述的行为无关：(partition n coll)仅仅意味着(partition n n coll)，即按照n的步长进行分区，因此它_总是_有步长值，这仅决定了在开始下一个分区之前跳过coll中的多少元素。Alex所描述的行为不受步长值的影响。

填充集合只有在生成的最后一个分区可能不包含n个元素时才有意义。

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))