Сортированные коллекции: Как правильно получить (расширенные) срезы?

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)

Рациональное:

В настоящее время я перерабатываю сортированную ассоциативную коллекцию с возможностью возврата диапазонов предметов. Вполне вероятно, что я захочу хранить кортежи с маленькими целыми числами (или даже более патологически странными значениями, такими как Ellipsis) в коллекции (как ключи), и мне понадобится какой-то разумный способ отличить расширенные фрагменты от простых ключей

В одномерном случае это не проблема. Я не могу придумать ни одной реальной причины, по которой я хотел бы собирать значения типа slice, тем более что значения xrange функционально аналогичны и более узнаваемы для питонистов (по моему мнению). Все остальные расширенные конструкции слайса являются кортежами slice, Ellipsis или обычными значениями Python

Никакой другой тип расширенного среза, по-видимому, не используется для любого вида коллекций, кроме многомерных массивов, как в NumPy.

Мне нужно поддерживать n-мерные оси, похожие на окт-деревья или индексы GiS.

Answer 1

Поскольку нет возможности провести различие между вызовами u [x, y] и u [(x, y)], вам следует перенести одну из двух операций, которые вы пытаетесь определить, на фактический метод. Вы знаете, что-то с именем u.slice () или u.range () или u.getslice () или u.getrange () или что-то в этом роде.

На самом деле, когда я пишу свои собственные программы, я обычно нахожу, что когда я пытаюсь перегрузить операцию Python двумя совершенно разными семантиками, это означает, что обе вещей Я делаю нужно превратить в именованные методы! Потому что, если они настолько похожи в том смысле, что ни у одного из них нет явных преимуществ при использовании ярлыка braces [] getitem, то, вероятно, мой код станет более читабельным, если обе операции станут действительными, читаемыми явные имена методов.

Но трудно сказать больше, так как вы не сказали нам, как на земле вы попали в этот беспорядок. Почему вы хотите хранить вещи под кортежами и , чтобы получать разные вещи? Есть подозрение, что вы делаете что-то сложное для начала. : -)

Да, и другие языки с этой проблемой заставляют вас [1] [2] делать многомерный доступ, чтобы легко отличить его от [1,2]. Просто чтобы вы знали, что есть другой вариант.

Answer 2

В настоящее время я думаю об этом, чтобы просто позволить типам, которые обычно ассоциируются со срезами, быть не подлежащими сбору. Я не могу придумать ни одной разумной причины, почему кто-то хотел бы делать что-либо со значением slice или Ellipsis, за исключением использования их в выражениях индекса.

При случайном отклонении пользователь коллекции хочет отсортировать по кортежу (вместо чисел, строк, дат или любой другой очевидной вещи). Возможно, имеет смысл просто потребовать некоторой дополнительной лжи. Как пример ...

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

На самом деле не пробовал это с реальным кодом (на самом деле у него сейчас нет рабочего индекса GiS), но я подозреваю, что это может просто автоматически сделать правильную вещь, так как расширенный фрагмент - это кортеж длины один одно измерение), который оказывается кортежем.

Answer 3

С документы :

В формальном есть двусмысленность Синтаксис здесь: все, что выглядит список выражений также выглядит как список слайсов, поэтому любая подписка может быть интерпретируется как нарезка. Скорее, чем дополнительно усложняя синтаксис, это однозначно определив, что в этот случай интерпретация как подписка имеет приоритет над интерпретация как нарезка (это случай, если список слайсов не содержит правильный кусок, ни эллипсы). Так же, когда список слайсов имеет ровно один короткий срез и без запятой, интерпретация как простая нарезка имеет приоритет над этим как расширенная нарезка.

Поэтому я не думаю, что можно отличить u[1,2] -as-extended-slice от u[1,2] -as-tuple-key.