Python DB-API: как обрабатывать различные параметры?

Я реализую класс онтологии Python, который использует серверную часть базы данных для хранения и запроса онтологии. Схема базы данных фиксированная (указывается заранее), но я не знаю, какой тип движка базы данных используется. Однако я могу положиться на тот факт, что интерфейс Python ядра базы данных использует Python DB-API 2.0 ( PEP 249 ). Простая идея состоит в том, чтобы позволить пользователю передать совместимый с PEP 249 объект Connection конструктору моей онтологии, который затем будет использовать различные жестко запрограммированные запросы SQL для запроса базы данных:

class Ontology(object):
    def __init__(self, connection):
        self.connection = connection

    def get_term(self, term_id):
        cursor = self.connection.cursor()
        query = "SELECT * FROM term WHERE id = %s"
        cursor.execute(query, (term_id, ))
        [...]

Моя проблема в том, что разные серверным модулям базы данных разрешено поддерживать различные маркеры параметров в запросах, определяемых атрибутом paramstyle внутреннего модуля. Например, если paramstyle = 'qmark' , интерфейс поддерживает стиль вопросительного знака ( SELECT * FROM term WHERE id =? ); paramstyle = ' numeric ' означает числовой позиционный стиль ( SELECT * FROM term WHERE id =: 1 ); paramstyle = 'format' означает стиль строки формата ANSI C ( SELECT * FROM term WHERE id =% s ). Если я хочу, чтобы мой класс мог обрабатывать различные серверные части базы данных, мне кажется, что мне нужно подготовиться ко всем стилям маркеров параметров. Похоже, что это лишает меня всей цели общего API БД, поскольку я не могу использовать один и тот же параметризованный запрос с разными базами данных.

Есть ли способ обойти это, и если да, то какой подход лучше? API БД не указывает на наличие универсальной функции экранирования, с помощью которой я могу дезинфицировать свои значения в запросе, поэтому выполнение экранирования вручную не является вариантом. Я не Я не хочу добавить к проекту дополнительную зависимость, используя еще более высокий уровень абстракции (например, SQLAlchemy).