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

Question

2个问题
- clojure.core/partition的文档字符串没有清楚地说明“最后一个分区”的含义。
- partition的行为异常，我认为它确实有一个错误。

请查看这个

(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是一个可能的解释(尤其是与同分的分所有行为相比)，但我认为改变当前行为可能会对现有用户产生破坏性的影响。

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中跳过多少元素。亚历克斯所描述的行为不受步长值的影响。

仅当要生成的最后一个分区不包含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))