在 `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

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

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

---

我不是Clojure核心团队的一员，所以不能代表他们发言，但我可以说他们肯定重视核心函数的行为向后兼容性。鉴于`partition`函数的当前行为已经这样至少有10年的历史了，他们很可能不愿意改变其行为，以防任何依赖于它的现有代码，其所有细节。

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

还有一些网站，如 https://docs.clojure.org/clojure.core/partition，允许社区贡献的功能行为示例，附有解释的注释，提供了比大多数Clojure核心函数在文档字符串中可能包含的更广泛的示例。

---

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