Обработка многих необязательных импортов - PullRequest
0 голосов
/ 25 апреля 2019

У нас есть файл с несколькими разными классами, которые делают одно и то же, но по-разному.Каждый из этих классов имеет несколько импортов из внешних пакетов.

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

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

Я видел, что некоторые люди справляются с этим просто:

try:
    import module
except ImportError:
    try:
        import other_module
    except ImportError:
        raise

Однако у нас довольно много таких импортов и маргариток-процессирование их таким образом трудно поддерживать и неуклюже.

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

Наконец, мы могли бы просто добавить импорт в пространства имен классов:

class EngineOne:

    import module

    def methodology_one(self):

        self.module.function()


class EngineTwo:

    import other_module

    def methodology_two(self):

        self.other_module.function()

Это, однако, кажется оченьнестандартный, и я не могу найти реальных примеров, где люди сделали это.self.module.function() также выглядит очень странно, даже если имеет смысл иметь импорт в качестве переменных класса.

Я кратко ознакомился с некоторыми распространенными пакетами данных, которые я установил, но не могу найти ни одного, где используются подобные вещи.

Я нашел несколько вопросов о стековом потоке, которыекратко упомянули условный импорт, такой как этот и этот , но ни один, где есть конкретные примеры, которые хорошо описывают наш случай.

Спасибо за любую помощь.

1 Ответ

0 голосов
/ 25 апреля 2019

В конце мы решили разделить классы для каждой методологии на отдельные файлы, а затем поместить их в каталог с __init__.py.Затем этот __init__.py содержит некоторую логику, которая перебирает импорт, улавливая любые ошибки импорта.

Структура была:

main_dir
   - __init__.py
   - engines.py
      - class EngineOne
         ...
      - class EngineTwo
         ...
      - class EngineThree
         ...
   - run.py
   - ...

В то время как сейчас структура имеет вид:

main_dir
   - __init__.py
   - engines_dir
      - __init__.py   # Contains logic for import checking
      - method_one.py
         - class EngineOne
            ...
      - method_two.py
         - class EngineTwo
            ...
      - method_three.py
         - class EngineThree
            ...
   - run.py   # Just imports the engines_dir module
   - ...

Мы сделали это по нескольким причинам.

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

  • Нам также необходимо импортировать наш пакет,Это означает, что включение проверки импорта в файл запуска могло бы вызвать проблемы при импорте непосредственно в другое место.

Хотя это ответ, я не уверен в этом ответ .Возможно, есть лучшие способы сделать это, но это хорошо работает для нас.Я не буду отмечать вопрос как решенный, если будет дан лучший ответ.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...