Я пишу приложение на Python, и у меня есть ряд универсальных переменных (таких как ссылка на главное окно, пользовательские настройки и список активных элементов в пользовательском интерфейсе), которые должны быть доступный из всех частей программы 1. Я только что понял, что я назвал модуль globals.py
, и я импортирую объект, содержащий эти переменные, с инструкцией from globals import globals
в верхней части моих файлов.
Очевидно, это работает, но я немного склонен к тому, чтобы называть мой глобальный объект таким же, как встроенный Python. К сожалению, я не могу придумать для этого более правильное соглашение об именах. global
и all
также являются встроенными Python, universal
кажется неточным, state
на самом деле не является правильной идеей. Я склоняюсь к static
или env
, хотя оба имеют определенное значение в компьютерных терминах, что предполагает другое понятие.
Итак, что (в Python) вы бы вызвали модуль, который содержит переменные глобальные для всех ваших других модулей?
1 Я понимаю, что могу передать эти (или единственный объект, содержащий их) в качестве переменной в каждую другую функцию, которую я вызываю. Это оказывается недопустимым, а не только потому, что код запуска и функции очень уродливый.
Я бы назвал его env
. Там небольшой риск, что кто-то смутит его с помощью os.environ
(особенно, если вы организуете свой код, чтобы его можно было назвать myapp.environ
).
Я также сделал бы все, что было бы показано в myapp.environ
свойстве класса, чтобы я мог установить точки останова в сеттер, когда наступит день, который мне нужно.
Я бы попытался полностью исключить такой глобальный контейнерный модуль и вместо этого поместить эти переменные в свои собственные модули, которые затем могут быть импортированы из всех частей системы.
Например, главное окно, вероятно, перейдет в переменную в main.py
. Пользовательские настройки могут войти в usersettings.py
, который предоставит функции для просмотра и изменения настроек.
Если другой части системы необходимо получить доступ к пользовательским настройкам, это просто:
from usersettings import get_setting, set_setting
...
# Do stuff with settings
Аналогичный подход можно было бы использовать для других вещей, которые должны быть доступны на глобальном уровне. Это приводит к более четкому разделению проблем и более тестируемого кода, поскольку вы можете тестировать модули изолированно, не зависимо от модуля globals
все время.
`config` or `settings`
from globals import Globals
Это устранит конфликт, а также последует рекомендациям PEP 8.
Кроме того, в других подобных случаях Роза Тезаурус - ваш друг. Я всегда держу копию рядом.
top
? top_level
?
global
- это ключевое слово, а не встроенное. "globals" - это не ключевое слово, а встроенная функция. Его можно назначить, но это плохая практика. Контроллеры кода, такие как pylint и pychecker, могут поймать эти случайные задания. Как насчет config
?