Python таблица В оперативной памяти

Теперь, как мне выполнить поиск, если 'column1' имеет 'value11'

any (arow ['column1'] == 'value11' для строки в table.iteritems ())

Неправильно ли этот метод формирования таблиц ?

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

Есть ли лучший способ реализовать такие таблицы с более простым поиском?

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

У меня были аналогичные, но не идентичные потребности в большом внутреннем приложении, которое я поддерживаю на работе, за исключением того, что индексы строк являются целыми числами (только имена столбцов являются строками), порядок столбцов важен, а рабочая нагрузка больше связана с «редактированием» "таблица (добавление, удаление, изменение порядка строк или столбцов, переименование столбцов и т. д.).Я начал с таблицы, раскрывающей нужную мне функциональность, с простейшей грубой внутренней реализации (список dicts плюс список имен столбцов для упорядочивания столбцов); и к настоящему времени я развил его (независимо от фактических частей «уровня приложения», но на основе их профилирования и тестирования производительности) до совершенно разных реализаций (в настоящее время основанных на numpy ).

Я думаю, вам следует действовать в том же духе: «облеките» вашу текущую реализацию в красивый «интерфейс» со всеми необходимыми методами, профилируйте свое приложение - если этот объект таблицы не является узким местом производительности, все готово; если это является узким местом, вы можете оптимизировать реализацию (поэкспериментировать, измерить, повторить ;-), не мешая остальным частям вашего приложения.

Наследование от dict не является хорошей идеей, потому что вы, вероятно, не хотите раскрывать всю богатую функциональность dict ; плюс, то, что вы делаете, грубо говоря, является неэффективной реализацией collections.defaultdict (dict) . Итак, инкапсулируйте последнее:

import collections

class Table(object):
    def __init__(self):
        self.d = collections.defaultdict(dict)
    def add(self, row, col, val):
        self.d[row][col] = val
    def get(self, row, col, default=None):
        return self.d[row].get(col, default)
    def inrow(self, row, col):
        return col in self.d[row]
    def incol(self, col, val):
        return any(x[col]==val for x in self.d.iteritems())

и т. Д. И т. Д. - напишите все методы, которые нужны вашему приложению, с полезными короткими именами, а затем, возможно, посмотрите, можете ли вы присвоить некоторым из них псевдонимы как специальные методы, если они ' re часто используется таким образом, например, возможно (при условии, что Python 2. * - требует немного другого синтаксиса в 3. *):

    def __setitem__(self, (row, col), val):
        self.add(row, col, val)

и так далее. Когда у вас работает код , затем , наступает подходящее время для профилирования, тестирования и, возможно, внутренней оптимизации реализации.