Какой способ идеально подходит для регистрации фабрики Python?

Question

Это вопрос о том, какой из этих методов будет считаться наиболее Pythonic . Я не ищу личные мнения, но вместо этого, что идиоматично. Мой фон не в Python, так что это поможет мне.

Я работаю над проектом Python 3, который является расширяемым. Идея похожа на фабричный шаблон, за исключением того, что она основана на функциях.

По сути, пользователи смогут создавать пользовательские функции (для пакетов и проектов), которые мой инструмент может определять и динамически вызывать. Он также сможет использовать карри для передачи аргументов (но этот код здесь не включен)

Моя цель состоит в том, чтобы следовать хорошей практике Pythonic. Я разрываюсь между двумя стратегиями. И, поскольку Python не является моей компетенцией, я хотел бы знать плюсы и минусы следующих практик:

1. Использовать декоратор

   registered = {}
   
   def factoried(name):
       def __inner_factory_function(fn):
           registered[name] = fn
           return fn
       return __inner_factory_function
   
   
   def get_function(name):
       return registered[name]
   

   Затем автоматически регистрируется следующая функция ...

   @factoried('foo')
   def build_foo():
     print('hi')
   

   Это кажется разумным, но кажется немного волшебным для тех, кто не знаком с декораторами.

2. Принудительное подклассирование абстрактного класса и использование __subclasses__()

   Если используются подклассы, регистрация не требуется. Однако я чувствую, что это заставляет определять классы, когда полный класс может быть ненужным. Кроме того, использование .__subclasses__() под капотом может показаться волшебным для потребителей. Однако даже Java можно использовать для поиска классов с аннотациями.

3. Явная регистрация

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

   def build_foo():
     # ...
   
   factory.register('foo', build_foo)
   

Answer 1

На этот вопрос нет ответа.

Единственными стандартными методами, поддерживаемыми Python Foundation, являются PEP 8 .

PEP 8 имеет очень мало связанных с вопросами «шаблонов» более высокого уровня, таких как этот, и, в частности, ничего не относится к вашему конкретному вопросу.

И, даже если это так, PEP 8 явно является лишь руководством для "кода, включающего стандартную библиотеку в основном дистрибутиве Python" , и Гвидо отклонил предложения, чтобы сделать его своего рода широким стандарт ранжирования, который должен применяться в каждом проекте Python.

Кроме того, это говорит о том, что это всего лишь руководство, а не жесткая рекомендация .

---

Конечно, есть субъективные причины отдавать предпочтение одному дизайну другому.

В идеале, эти субъективные причины, как правило, обусловлены консенсусом сообщества в отношении того, что является «идиоматическим» или «питоническим». Но этот общественный консенсус нигде не записан как какой-то объективный источник, который вы можете привести.

Могут быть аргументы, которые апеллируют к Дзен Питона , но это просто попытки Тима Питерса превратить собственные субъективные ориентиры Гвидо в набор содержательных звуковых фрагментов, а не объективный источник. (И любой, кто кратко рассмотрит, например, список python-ideas, может увидеть, что обе стороны почти любого вопроса могут обратиться к дзен…)