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）分区，所以不行。

Comments

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

当我尝试调用`partition`函数并使用自定义`step`参数（一个与`n`不同的值）时，所描述的问题会出现。到目前为止，还没有提及关于`step`参数的回答。

---

我不是Clojure核心团队的一员，因此不能为他们发言，但可以说他们确实重视核心函数的行为向后兼容性。鉴于`partition`的当前行为已经以这种方式存在至少10年，他们很可能不愿意改变其行为，以免任何现有的工作代码依赖于它，包括其所有细节。

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

还有一些网站，例如 https://docs.clojure.org/clojure.core/partition，允许社区贡献核心函数行为的示例，并附有解释说明的评论，这比大多数Clojure核心函数将包含在其文档字符串中的示例要广泛得多。

---

`step`参数与描述的行为无关：(partition n coll)just means (partition n n coll)，即以n为步长的partition，因此它_总是_有步长值，这仅决定了在开始下一个partition之前在coll中跳过多少个元素。亚历克斯描述的行为不受步长值的影响。

填充集合只有在将要生成的最后一个partition中没有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))