Как мне назвать мой глобальный модуль в Python?

1

Я пишу приложение на Python, и у меня есть ряд универсальных переменных (таких как ссылка на главное окно, пользовательские настройки и список активных элементов в пользовательском интерфейсе), которые должны быть доступный из всех частей программы 1. Я только что понял, что я назвал модуль globals.py, и я импортирую объект, содержащий эти переменные, с инструкцией from globals import globals в верхней части моих файлов.

Очевидно, это работает, но я немного склонен к тому, чтобы называть мой глобальный объект таким же, как встроенный Python. К сожалению, я не могу придумать для этого более правильное соглашение об именах. global и all также являются встроенными Python, universal кажется неточным, state на самом деле не является правильной идеей. Я склоняюсь к static или env, хотя оба имеют определенное значение в компьютерных терминах, что предполагает другое понятие.

Итак, что (в Python) вы бы вызвали модуль, который содержит переменные глобальные для всех ваших других модулей?

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

Теги:
naming-conventions
global-variables

6 ответов

1
Лучший ответ

Я бы назвал его env. Там небольшой риск, что кто-то смутит его с помощью os.environ (особенно, если вы организуете свой код, чтобы его можно было назвать myapp.environ).

Я также сделал бы все, что было бы показано в myapp.environ свойстве класса, чтобы я мог установить точки останова в сеттер, когда наступит день, который мне нужно.

3

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

Например, главное окно, вероятно, перейдет в переменную в main.py. Пользовательские настройки могут войти в usersettings.py, который предоставит функции для просмотра и изменения настроек.

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

from usersettings import get_setting, set_setting
...
# Do stuff with settings

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

  • 0
    Называя забаву в стороне, это, вероятно, лучший образ действий ... +1.
  • 0
    У меня есть те части, которые имеют смысл разбить на их отдельный модуль, который будет импортирован отдельно. Но есть много объектов, которые просто должны быть доступны везде. Поскольку число глобальных переменных умножается, я начинаю импортировать каждый модуль из любого другого модуля. И затем я начинаю сталкиваться с проблемами упорядочения, когда мне приходится перемещать код в разные модули, чтобы его можно было импортировать отдельно двумя другими модулями, не влияя друг на друга. Наличие единого глобального модуля значительно снижает сложность кода, с очень небольшим компромиссом.
1
`config` or `settings`
0
from globals import Globals

Это устранит конфликт, а также последует рекомендациям PEP 8.

Кроме того, в других подобных случаях Роза Тезаурус - ваш друг. Я всегда держу копию рядом.

0

top? top_level?

0

global - это ключевое слово, а не встроенное. "globals" - это не ключевое слово, а встроенная функция. Его можно назначить, но это плохая практика. Контроллеры кода, такие как pylint и pychecker, могут поймать эти случайные задания. Как насчет config?

  • 0
    globals () - встроенная функция.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню