Имена GET_PARAM_EX_2 и GET_QUOTE_LEVEL2

[Abrosimov-a-a]

Проблема:

Разный стиль именования: GET_PARAM_EX_2 и GET_QUOTE_LEVEL2, а именно _2 и 2.

Мотивация:

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

Варианты решения:

• Переименовать GET_PARAM_EX_2 в GET_PARAM_EX2. Нарушит обратную совместимость.
• Добавить еще одну переменную GET_PARAM_EX2 = 41 в RPC.proto. Сохранит обратную совместимость и решит проблему.
• Ничего не делать. Все обработать регулярками, но для GET_PARAM_EX_2 писать отдельный if.

[Enfernuz]

Я за третий вариант 😃 Всё же эти названия не случайны и отражают соответствующие наименования в QLua.
А можно пример кода для конверсии на клиенте (чтобы яснее представлять контекст)?

[Abrosimov-a-a]

Не отражают. По документации есть две функции с одинаковым именованием: getParamEx2 и getQuoteLevel2. Мне кажется, что они должны переводиться в snake_case одинаково.

import re


def camel_to_snake(name: str,
                   case: str = 'upper',
                   pattern1: re.Pattern = re.compile(r'(.)([A-Z][a-z]+)'),
                   pattern2: re.Pattern = re.compile(r'([a-z])([A-Z])'),
                   pattern3: re.Pattern = re.compile(r'(__)'),
                   ) -> str:
    """Переводит строку из camelCase, PascalCase в UPPER_SNAKE_CASE."""
    assert case in ('upper', 'lower'), ("'case' должен быть: 'upper' или "
                                        f"'lower', получен: {case}")
    # Удалить это после решения:
    # https://github.com/Enfernuz/quik-lua-rpc/issues/44#issue-669922435
    if name == 'getParamEx2':
        return 'GET_PARAM_EX_2'
    name = pattern1.sub(r'\1_\2', name)
    name = pattern2.sub(r'\1_\2', name)
    name = pattern3.sub(r'_', name)
    name = getattr(name, case)()
    return name

[Enfernuz]

Прошу прощения за задержку. У меня хоть и не возникали проблемы такого плана, когда я писал Java-клиент, но, думаю, тут в плане оптимальности трейдоффа усилий и полученной пользы подходит вариант №2: добавить новый метод, дублирующий функциональность старого. Если ещё PR такого нет в закромах, то постараюсь сотворить до конца этой недели.