Clojure核心的`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视为可能的解释（特别是与相同情况的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))