Нет ли такой библиотеки, которая отфильтрует список, содержащий однотипные объекты на основе заданного SQL запроса

Что-нибудь вроде:
>>> sql = "SELECT field1,field2 FROM List WHERE field3 = 0"
>>> filteredList = getListFromSomewhere( sql )
>>> print "\n".join( [ f.field3 for f in filteredList ] )
0
0
...
0
>>>

Зачем:
Пользователь работает из комманд лайна и получает довольно обширные списки с большим количеством полей. Очень часто он хочет, чтобы инормация была отфильтрована или соответствующим образом сгруппирована. При чем, желательно это сделать это легко и быстро. В идеале пользователь вообще мало знаком с питоном. Сейчас в качестве параметра ф. getListFromSomewhere передается лямбда. Но мне кажется задание правил фильтрации через SQL гораздо более удобным в данной ситуации. Решение, вроде сохранить сначала весь список в таблицу SQLite а потом извлечь оттуда нужные данные, кажется костылем. Может я не прав?

А>Нет ли такой библиотеки, которая отфильтрует список, содержащий однотипные объекты на основе заданного SQL запроса

А>Что-нибудь вроде:
>>>> sql = "SELECT field1,field2 FROM List WHERE field3 = 0"
>>>> filteredList = getListFromSomewhere( sql )
>>>> print "\n".join( [ f.field3 for f in filteredList ] )
А>0
А>0
А>...
А>0
>>>>

А>Зачем:
А>Пользователь работает из комманд лайна и получает довольно обширные списки с большим количеством полей. Очень часто он хочет, чтобы инормация была отфильтрована или соответствующим образом сгруппирована. При чем, желательно это сделать это легко и быстро. В идеале пользователь вообще мало знаком с питоном. Сейчас в качестве параметра ф. getListFromSomewhere передается лямбда. Но мне кажется задание правил фильтрации через SQL гораздо более удобным в данной ситуации. Решение, вроде сохранить сначала весь список в таблицу SQLite а потом извлечь оттуда нужные данные, кажется костылем. Может я не прав?

То есть нужна библиотека, которая применит SQL запрос не к базе данных, а к вашему списку? Очень вряд ли такая есть.

Отчасти, наверное, потому что в питон уже встроена подобная функциональность.

print "\n".join( (f.field1, f.field2) for f in List if f.field3 == 0 )

Пользователи могут вводить подобные выражения.

T>

T>print "\n".join( (f.field1, f.field2) for f in List if f.field3 == 0 )
T>

T>Пользователи могут вводить подобные выражения.

Вот хотелось бы их от этого избавить как раз. В идеале, хотелось бы, чтобы пользователь работал не напрямую с интерпретатором питона, а со строкой ввода, которая уже обрабатывалась бы скриптом.
Юзер — пытается диагностировать проблему в некой системе, питон — лишь вспомогтаельная прослойка. И по возможности нужно этого самого юзера избавить от лишних подробностей.

T>>

T>>print "\n".join( (f.field1, f.field2) for f in List if f.field3 == 0 )
T>>

T>>Пользователи могут вводить подобные выражения.

А>Вот хотелось бы их от этого избавить как раз. В идеале, хотелось бы, чтобы пользователь работал не напрямую с интерпретатором питона, а со строкой ввода, которая уже обрабатывалась бы скриптом.
А>Юзер — пытается диагностировать проблему в некой системе, питон — лишь вспомогтаельная прослойка. И по возможности нужно этого самого юзера избавить от лишних подробностей.

Вам виднее, конечно, чем именно там недовольны пользователи и зачем их избавлять от питона. (потому что если их устраивает, то ничего трогать и не надо)

Можно не давать лишних подробностей; можно сообщить только то, что необходимо для решения повседневных задач.

Строку ввода, которая обрабатывается скриптом сделать очень легко. Вопрос в том как будет обрабатываться то, что они введут. Возможно, вы будете велосипедить ещё один питон/lua.

T>Вопрос в том как будет обрабатываться то, что они введут. Возможно, вы будете велосипедить ещё один питон/lua.

Вот! Именно хотелось бы избежать велосипедов. SQL вполне себе подходит для описания правил фильтрации и сортировки. Ну раз нет либы, на нет — и суда нет )).
А была бы такая либа полезна более чем в одном ( моем ) случае?

T>>Вопрос в том как будет обрабатываться то, что они введут. Возможно, вы будете велосипедить ещё один питон/lua.

А>Вот! Именно хотелось бы избежать велосипедов. SQL вполне себе подходит для описания правил фильтрации и сортировки. Ну раз нет либы, на нет — и суда нет )).
А>А была бы такая либа полезна более чем в одном ( моем ) случае?

Python/Lua в данном случае не велосипед, потому что они уже написаны.

Такая либа есть. Как вы правильно заметили в первом сообщении, это SQLite. Он может держать базу в памяти.

Здравствуйте, Аноним, Вы писали:

А>Вот! Именно хотелось бы избежать велосипедов. SQL вполне себе подходит для описания правил фильтрации и сортировки. Ну раз нет либы, на нет — и суда нет )).

Есть LogParser, делает как раз это — применяет SQL к данным из не-SQL источника. Вызывается либо как консольное приложение, либо через COM-интерфейсы, так что в некотором смысле либа.

P.S. А то, что "SQL вполне себе подходит", это ты решил или таки пользователи? А то здесь может ждать большое разочарование...