выбор между Модулями и Классами

Второй подход только существенно отличается от первого подхода, если Вам сохранили состояние приложения в экземпляр из AppState, в этом случае Ваша жалоба не применяется. Если Вы просто храните материал в классе и используете статические / методы класса, Ваш класс не отличается, чем модуль, и это был бы pythonic к вместо этого, на самом деле имеют его как модуль.

Походит на классическую загадку:-).

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

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

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

Почему бы не пойти с экземпляром того класса? Тем путем Вы могли бы даже быть в состоянии позже иметь 2 различных "сессии", работающие, в зависимости от того, какой экземпляр Вы используете. Это могло бы сделать это более гибким. Возможно, добавьте некоторый метод get_appstate() к модулю так это instanciates класс однажды. Позже, если Вы могли бы хотеть несколько экземпляров, можно изменить этот метод, чтобы в конечном счете взять параметр и использовать некоторый словарь и т.д. для хранения тех экземпляров.

Вы могли также использовать декораторов свойства btw, чтобы сделать вещи более читаемыми и иметь гибкость хранения его, как и где Вы хотите это хранилища.

я соглашаюсь, что это было бы больше pythonic для использования подхода модуля вместо classmethods.

BTW, я не такой большой поклонник имения в наличии вещей глобально некоторым "волшебством". Я использовал бы некоторый явный вызов для получения той информации. Тогда я знаю, куда вещи прибывают из и как отладить его, когда вещи перестали работать.

Рассмотрите этот пример:

configuration
|
+-> graphics
|   |
|   +-> 3D
|   |
|   +-> 2D
|
+-> sound

реальный вопрос: Каково различие между классами и модулями в этой иерархии, поскольку это могло быть представлено обоими средствами?

Классы представляют типы. При реализации решения с классами вместо модулей Вы в состоянии проверить графический объект, поскольку это - надлежащий тип, но запишите универсальные графические функции.

С классами можно генерировать параметризованные значения. Это означает, что возможно инициализировать по-другому звуки класс с конструктором, но трудно инициализировать модуль с различными параметрами.

точка, что Вы действительно что-то другое с точки зрения моделирования.

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

from appstate import AppSate

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

второй подход, IMO, более гибкий и соответствующий требованиям завтрашнего дня. Для предотвращения более длинных строк кода Вы могли использовать from appstate import AppState вместо всего import appstate.