Numpy: 用椭圆形的索引行为是不直观的。

这似乎是一个特别令人讨厌的极端情况-我想我们认为...强制两个高级索引0和[0]被认为是不相邻的-即使他们索引相邻的轴。

尝试复制numpy索引时，我们遇到了此问题。 我认为这是两个规则之间的怪异互动：

• 省略号扩展为完整切片的元组，每个切片均被视为基本索引
• 混合顺序的高级索引和基本索引会触发转置操作。

之所以会触发这种特殊情况，是因为0-d元组（当...与所有存在的索引一起使用时）仍应视为基本索引块，而此时它实际上是不可见的。

我同意这一切都令人困惑，即使不检查这里发生的事情，我什至无法确定。 但是，对我来说，这似乎是正确的选择。

为什么它应该是真正的“隐形”？ ...对于任意数量的尺寸应具有相同的行为。 为此，它必须在所有情况下触发移调。 即想象一下组织为series, ..., color事物，其中...是用户定义的，可以为0-d。 如果要编写一个程序来处理该数据，则需要将索引按预期无序地转换...扩展（或不扩展）的范围。

最后，这简直令人困惑，我们必须更认真地选择.oindex和.vindex等来解决它： https :

我支持@seberg的观点，即当前行为是最好的概括。 我们当然可以确保文档更加清晰。

我不知道那个建议，谢谢@seberg的参考！

让我改一下，以确保我理解您的论点。 假设我们标记了高级索引A和基本索引B ，如上所述，我将重新排序操作称为（广义）转置。 在您的示例中，我们有四种情况：

• [A1, ..., A2]和[B1, ... A1] ：无论...扩展，这些情况都会触发转置为[A1, A2, ....]和[A1, B1, ...] 。
• [A1, ..., B1]和[B1, ..., B2] ：这些情况没有。

一旦您知道series和color属于哪个类（A或B），这些规则就是一致的，而与...扩展方式无关。 这等效于将...视为基本索引的块（可能为0-d）。 将0-d ...作为特例将是不好的，因为转置取决于用户输入的是2维数组还是3维或更多维的数组。 我同意，这是一个糟糕的地方。

我的直觉是0元块应该是无操作的，是由元组的行为决定的，对于任何i ，

i: int
M: Tuple[int, ...]
N = ()
assert M[:i] + N + M[i:] == M

这与numpy索引约定冲突，后者导致以上四种情况，具体取决于i是什么。 这与移调操作本身有关，而不是与...的处理方式有关，这是NEP21提案的一个论据。

在开发过程中，我们将切换索引的方式，并插入...以便将来验证代码，并且在魔术般转换形状时会感到非常困惑。 空的...情况尤其违反直觉，这加剧了这种情况。

谢谢参观！ 如果您愿意，我可以提交文件PR。

@antonl doc PR始终受到欢迎，这里有许多改进的可能。