在 `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个元素进行完整的分区。如果不能完成完整的分区，则完成。如果您提供了一个填充集合（pad coll），它将使用该集合来完成无法完成完整分区的第一个分区（这将是最后一个分区）。

• 选择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中跳过多少个元素。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))