排序集合：如何正确获取（扩展）切片？

Question

我如何解决这个问题？在

>>> class unslice:
...     def __getitem__(self, item): print type(item), ":", item
...
>>> u = unslice()
>>> u[1,2]    # using an extended slice
<type 'tuple'> : (1, 2)
>>> t = (1, 2)
>>> u[t]  # or passing a plain tuple
<type 'tuple'> : (1, 2)

理性的：

我目前过度设计了一个能够返回项目范围的排序关联集合。我很可能希望将小整数的元组（或者更病态的wierd值，比如省略号）存储在集合中（作为键），并且需要某种合理的方法来区分扩展切片和普通键

在一维的情况下，这有点不成问题。我想不出有什么真正的理由要收集slice类型的值，特别是因为xrange值在功能上与pythonistas相似，并且更容易识别（在我的判断中）。所有其他扩展切片构造都是slice、Ellipsis或普通的旧python值的元组

除了多维数组（如NumPy）之外，似乎没有其他类型的扩展切片用于任何类型的集合。在

我确实需要支持n维轴，类似于oct树或GiS索引。在

Answer 1

我目前的想法是简单地让通常与切片相关的类型不可收集。除了在下标表达式中使用它们之外，我想不出任何合理的理由来解释为什么任何人都想对slice值或Ellipsis做任何事情。在

如果集合的用户希望对元组进行排序（而不是数字、字符串、日期或任何其他明显的东西），那么只需要一些额外的代码就可以了。举个例子。。。在

>>> u[t]
<type 'tuple'> : (1, 2)
>>> u[t,]
<type 'tuple'> : ((1, 2),)

我还没有用实际的代码尝试过（目前还没有一个有效的GiS索引），但是我怀疑这可能会自动做正确的事情，因为扩展切片是一个长度为1（一维）的元组，它恰好是一个元组。在

Answer 2

来自the docs：

There is ambiguity in the formal syntax here: anything that looks like an expression list also looks like a slice list, so any subscription can be interpreted as a slicing. Rather than further complicating the syntax, this is disambiguated by defining that in this case the interpretation as a subscription takes priority over the interpretation as a slicing (this is the case if the slice list contains no proper slice nor ellipses). Similarly, when the slice list has exactly one short slice and no trailing comma, the interpretation as a simple slicing takes priority over that as an extended slicing.

因此，我认为不可能区分u[1,2]-作为扩展切片与{}-作为元组键。在

Answer 3

由于无法区分调用u[x，y]和u[（x，y）]，您应该将尝试定义的两个操作之一移到实际方法。你知道的，一些叫做u.slice（）或u.range（）或u.getslice（）或u.getrange（）之类的东西。在

实际上，在编写我的自己的程序时，我通常会发现，当我试图用两种截然不同的语义重载Python操作时，这意味着我正在做的这两件事都需要转换为命名方法！因为如果这两个操作在意义上非常相似，没有一个明显优于使用大括号[]getitem快捷方式，那么如果两个操作都得到真实、可读、显式的方法名，那么我的代码可能会更具可读性。在

但是，很难说更多，因为你没有告诉我们你到底是怎么陷入这种困境的。为什么你要同时在元组下存储东西，而在元组中获取范围呢？有人怀疑你在做一些复杂的事情。：-）

哦，还有其他语言有这个问题，让你说一个[1][2]做多维存取，很容易与a[1，2]区分开。只是让你知道还有另一个选择。在