Быстрый настраиваемый парсер обратных польских нотаций с биниднгами для питона?

пишется в 15 строчек же

Внезапно, Common Lisp

А батарейки тут: https://github.com/Lovesan/bike/

Ему на си надо, а не ещё тормознее.

Вероятно ты ищешь pyforth.

Погулите «Быстрый настраиваемый парсер обратных польских нотаций с биниднгами для питона?»

Владимир

https://ru.wikiversity.org/wiki/Обратная_польская_запись:_примеры_реализации

Гуглил «парсер обратных польских нотаций питона».

Владимир

Лет пять назад реализовал декомпилятор байт кода Firebird процедур /ну надо было. Процентов на 98 позволяет получить исходник. Большего мне и не нужно было/.
Их байт код - обратная польская запись.

Вообщем ТС стек спасет /как и меня/.

Владимир

Bison, flex

Это?
https://pypi.org/project/bison/
https://pypi.org/project/flex/

Владимир

Кстати неплохой совет /все равно не понятно что за задача у ТС/.

Владимир

Нет.

https://en.wikipedia.org/wiki/GNU_Bison

https://en.wikipedia.org/wiki/Flex_(lexical_analyser_generator)

https://en.wikipedia.org/wiki/Comparison_of_parser_generators

Владимир

Для питона из современного неплохо выглядит lark. В списке википедии его нет.

вот это вот очень похоже на то что мне нужно, благодарю!

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

Сейчас у меня запросы это структура вида

{
   'or':[
      {'key':'label', 'value':'label1', 'match':'=='},
      {'and':[
         {'key':'label', 'value':'label2', 'match':'!='},
         {'or':[
            {'key':'from', 'value':'from1', 'match':'=='},
            {'key':'from', 'value':'from2', 'match':'=='},
            {'and':[
               {'key':'label', 'value':'label3', 'match':'!='},
               {'key':'from', 'value':'from3', 'match':'=='},
            ]},
            {'key':'label', 'value':'label4', 'match':'=='},
         ]},
      ]},
      {'key':'from', 'value':'from4', 'match':'=='},
      {'key':'from', 'value':'from5', 'match':'=='},
   ]
}

Парсер RPN - это str.split. Что тебе в нём не хватает?

А вообще интересно зачем RPN мог вообще кому-то понадобиться. Как вариант этого вопроса, почему RPN использовали в RRDTool вместо нормальных выражений. По мне так сейчас RPN нужен только чтобы детей учить на первых уроках программирования, когда скобки им ещё сложно (что, вообще, спорно), а для практического применения готовых парсеров чего угодно, используемых одной строчкой, вагон и тележка.

На будущее.

В SQLite имеется https://www.sqlite.org/vtab.html.
Если кратко - можно разработать SQL запросы к различным наборам данных.
Например для себя реализовал возможность выполнения SQL запросов к DBF, использующих CDX файлы /обеспечено использование CDX на все 100/.

PS: Потрудитесь и - «Будете счастливы».

Владимир

Sorry.

Если кратко - можно разработать SQL запросы к различным наборам данных.

Если кратко - можно разработать возможность выполнения SQL запросов к различным наборам данных.

Владимир

извиняюсь, а причем тут sqlite? субд другая, даже не sql-like и даже не реляционка. прикрутить сюда sqlite будет ох как непросто :)

извиняюсь, а причем тут sqlite? субд другая, даже не sql-like и даже не реляционка. прикрутить сюда sqlite будет ох как непросто :)

Вы ничего не поняли.

Еще раз акцентирую использование API virtual table позволит вам
реализовать возможность выполнения SQL запросов к любому типу данных /даже обычным текстовым файлам/.

Владимир

прикрутить сюда sqlite будет ох как непросто :)

Боягус.
Можно прикрутить!
И можно будет к вашей «не реляционки» выполнять SQL запросы.

Владимир

да задача то весьма узко-специфичная - для одной крайне-специфичной субд нужен какойнить человекочитаемый язык запросов

Ну так напиши сперва этот язык запросов.
А то, ты пытаешься без начального понимания своего языка запросов положить его на конкретные реализации: скобочный json и бескобочную польскую нотацию.

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

Это семантическая деталь реализации твоего языка не решается присутствем или отсутствием скобок в языке описания. Ты пытаешься сделать то, чего сам не понимаешь.

пишется в 15 строчек же

Ну не в 15, допустим, если по-хорошему, но да.

гадалка напела? язык запросов есть, движок выполнения есть, оптимизатор плана есть. речь про удобное представления для этого языка.

Уверены? У меня в голове SQL както плохо укладывается на графовые субд с совершенно иной моделью запросов. А если оставить от sql только крошечный кусочек - то зачем он нужен, это ведь дизориентирует.

Скорее всего вам не все «можно говорить», но любопытно, что за СУБД, почему другие не устроили ...?

Владимир

речь про удобное представления для этого языка

Речь не про удобное представление, а про то, что ты поставил перед фактом, что ты уже выбрал обратную польскую нотацию. А нам надо придумать оправдание твоему выбору, предоставивь быстрый парсер (который проще написать самому), и вписавь его в твой язык запросов (который мы не знаем).
Особенно позабавил «механизм отслеживания циклических ссылок», который не про язык запросов, а про внутреннее представление данных.
На счет твоего json-примера. Польская нотация предполагает, что ты заранее знаешь количество операндов у оператора. Придется придумывать одинаковые операторы разной арности and2, and3,..., andN, или придумывать метки начала(конца) операторов, аналоги скобок.

API virtual table предоставит вам возможность использовать ваши специфичные функции для доступа к данным.
Не утверждаю, что для вас это лучший путь.

Владимир

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

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

или придумывать метки начала(конца) операторов

ну метки начала-конца итак нужны, чтобы все это было удобно читать и писать.

Особенно позабавил «механизм отслеживания циклических ссылок», который не про язык запросов

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

ты поставил перед фактом, что ты уже выбрал обратную польскую нотацию
который не про язык запросов, а про внутреннее представление данных

ясно-понятно..

ну метки начала-конца итак нужны, чтобы все это было удобно читать и писать.

В обратной польской нотации не нужны такие метки. Ты не имеешь понятия про обратную польскую нотацию.

ты поставил перед фактом, что ты уже выбрал обратную польскую нотацию
который не про язык запросов, а про внутреннее представление данных

ясно-понятно..

Выдрал цитаты из разных абзацев, даже не предложений. Я не уверен, что ты можешь понимать написанное.
Дальнейший диалог не имеет смысла. Успехов.