Как стать автором
Обновить

Комментарии 12

Интересная вводная статья в Pyparsing. Но, конечно же, жду продолжения по
создание рекурсивных выражений, обработка таблиц, поиск по тексту с оптимизацией, резко ускоряющей сам поиск, и многое другое.
Вредный совет про звёздочку.
После того, как мы напишем парсер, мы заменим * на названия использованных нами классов.
Читай как «Забудем заменить»

А статья замечательная, спасибо.
Немного трогал pyparsing, даже делал небольшой рассказ про него (мало пояснений): nbviewer.ipython.org/urls/gist.githubusercontent.com/tbicr/cd584138ce183839946f/raw/e0c335bd57103e200279302eff3c667d5dd470b1/Pyparsion.ipynb. Если котортко дополнить, то мне сильно понравилось наличие setParseAction, addParseAction, которыми можно задать дополнительное поведение, как возвращая изменненное значение, так кидая ParseException, еще понарвилось что эскейпинг легко делать.
Для парсинга как правило используют регулярные выражения.

/зануда моде он
Вообще-то регулярные выражения не могут применяться для парсинга, поскольку не являются NP-полным языком.
Впрочем, введение рекурсивности в них снимает это ограничение.
/зануда моде офф
А статья неплохая, спасибо.
Насколько я помню, регулярные выражения, соответствующие регулярным грамматикам, ограничены в возможностях не из-за NP-неполноты (которая вообще тут ни при чём), а из-за того, что это самый простой и ограниченный тип грамматик по классификации Хомского.
На примере разбора одной строки как-то сложно оценить работу с этим модулем. В следующей статье по этой теме, если можно, хотелось бы увидеть что-то поувесистее… Например, парсер крошечного подмножества SQL — скажем, только SELECT и UPDATE, только из одной таблицы с опциональным WHERE, в котором может быть ровно один предикат с равенством.
К сожалению я не владею SQL запросами. Напишите пожалуйста пример текстовой строки — SQL запроса и что должно получиться на выходе.
Я обязательно разберу этот пример в одной из следующих статей.
В следующей статье я планирую написать про парсинг единиц измерения, затронув такие моменты, как:
1. Создание рекурсивных выражений
2. Парсинг русских букв на pyparsing
3. Учёт пробелов в pyparsing
Типовые запросы на SQL:

  • SELECT * FROM `t`
  • SELECT `c1`, `c2`, `c3` FROM `t` WHERE `c2` = 5
  • UPDATE `t` SET `c1` = 5
  • UPDATE `t` SET `c2` = `c1` + `c3` WHERE `c1` = 7

SELECT, UPDATE, FROM, WHERE, SET — ключевые слова. В кавычках — идентификаторы. Звездочка — то же, что и перечисление всех колонок в таблице. Скажем, для самого простого подмножества запрсов SELECT описание синтаксиса будет примерно такое:

SELECT * | `<имя колонки>` [, `<имя колонки>` ...]
FROM   `<имя таблицы>`
[WHERE `<имя колонки>` = <константа> | `<имя колонки>`]

Для UPDATE:

UPDATE `<имя таблицы>`
SET    `<имя колонки>` = <константа>
     | `<имя колонки>` = `<имя колонки>`
     | `<имя колонки>` = `<имя колонки>` <арифметическая операция: + - * /> `<имя колонки>`
[WHERE `<имя колонки>` = <константа> | `<имя колонки>`]
Во. А мне еще представляется, что осознать код, идущий после слов «В итоге наш код имеет следующий вид:», не сильно проще, чем базовые регулярные выражения.
При этом знание элементарных основ регулярок даёт непропорционально бОльшие возможности с инструментами, их поддерживающими. imho, конечно. Раз модуль есть, значит кому-то с ним удобнее, почему нет.
А можно сравнение с ply?
К сожалению не доводилось работать с этим инструментом. Однако я нашёл эту статью на хабре про ply. Я постараюсь в октябре-ноябре выпустить статью, разбирающую тот же самый пример на pyparsing. Соответственно будет возможность сравнить эти два инструмента.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.