Реализовать магические методы для базовых классов

[dveselov]

Например, в b88aba6 уже реализован метод __or__ для класса Rule, что дает возможность записать правила так:

A = rule(...)
B = rule(...)
C = (A | B).interpretation(object)

Сейчас такое же правило будет выглядеть так:

A = rule(...)
B = rule(...)
C = or_(A, B).interpretation(object)

Нужно посмотреть, какие методы можно реализовать (например, __and__ для конструкций вида (A & B) == and_(A, B) и __invert__ для ~(A & B) == not_(and_(A, B)))

[dveselov]

/cc @alexanderkuk

[kuk]

1. Неоднообразно. Например, человек пишет код с | & ~, тогда, например, из Наташи ему будет скопировать код неудобно
2. Неудобно форматировать.

NAME = (
    FIRST_LAST
    | LAST_FIRST
    | TITLE_FIRST_LAST
    | TITLE_LAST_FIRST
  ...
)

Также неоднообразное форматирование

NAME = FIRST_LAST \
    | LAST_FIRST \
    | TITLE_FIRST_LAST
...

3. Ошибки из-за отсутствуя скобочек. Например IS_FIRST | MAYBE_FIRST & is_title() не равно and(or_(IS_FIRST, MAYBE_FIRST), is_title())
4. Дополнительные усилия по разворачиванию. Предикат a & b & c это and_(and_(a, b), c), нужно написать код, который разворачивает это в and_(a, b, c)

[dveselov]

Ну, речь ведь не идет о полной замене - я предлагаю добавить ещё один вариант написания грамматик, который (иногда) позволит убрать многословность.
Проблема с копированием кода, на мой взгляд, немного притянута - вся суть библиотеки как-раз в том, что не нужно ничего писать вручную и копировать, т.е. можно просто сделать pip install ... и начать использовать готовые грамматики. А как (и через что :) они написаны - это дело десятое.
В остальном, я согласен, это добавит некоторые сложности.

[kuk]

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

Я считаю, что это введёт неоднообразность

Проблема с копированием кода, на мой взгляд, немного притянута - вся суть библиотеки как-раз в том, что не нужно ничего писать вручную и копировать

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

Короче, я против.

[dveselov]

Тогда давай сделаем так: в первом сообщении голосовалка, которая будет доступна ~месяц.
01.10.2017 посмотрим на результаты, ну и там уже решим, ок?

[kuk]

Я написал 4 аргумента против. Сколько аргументов за? Я вижу 1: краткость записи.

[dveselov]

Хорошо.

1. Неоднообразность можно убрать своим code style guide - например, писать на питоне можно как угодно, но обычно все придерживаются PEP-8. Если PEP-8 чем-то не устраивает, то используют свой вариант (например у Google есть свои рекомендации по стилю)
   Т.е. если кому-то не нравятся магические методы - их можно просто запретить использовать в коде (и обозначить это в своей документации, например).
2. В аналогичных проектах, например в Томита-парсере (или NLTK, да в любой грамматике, даже в той, что описывает питон), используется похожая нотация. Т.е. вариант с магическими методами может быть понятен для людей, которые раньше использовали какой-то другой парсер.
3. Ошибки из-за отсутствия скобочек могут быть и с вариантом без магических методов.
4. Если в некоторых грамматиках неудобно использовать магические методы, можно не использовать их. Пример с несколькими элементами внутри or_ действительно выглядит так себе с магическими методами (вот в данном случае можно и не использовать их или использовать, но страдать - это осознанный выбор).

Для меня большинство приведенных проблем выглядит как вкусовщина (кроме той, что придется писать код) и тут можно долго спорить.

[kuk]

Не, мне хотелось бы увидеть не критику моих минусов, а список плюсов. Я сейчас вижу два плюса:

1. Меньше кода
2. Синтаксис знакомый пользователям Томиты, NLTK