Когда использовать os.environ и когда использовать sys.argv? [Дубликат]
На самом деле, это не ошибка дизайна, и это происходит не из-за внутренних компонентов, а из-за производительности. Это происходит просто из-за того, что функции в Python являются первоклассными объектами, а не только частью кода.
Как только вы додумаетесь до этого, тогда это полностью имеет смысл: функция - объект, оцениваемый по его определению; параметры по умолчанию являются «данными-членами», и поэтому их состояние может меняться от одного вызова к другому - точно так же, как и к любому другому объекту.
В любом случае Effbot имеет очень хорошее объяснение причин это поведение в Значения параметров по умолчанию в Python . Я нашел это очень ясным, и я действительно предлагаю прочитать его, чтобы лучше узнать, как работают объекты функций.
3 ответа
1) Я бы рекомендовал максимально избегать переменных окружения.
Плюсы переменных окружения
- просты в использовании, потому что они видны из любого места.
Недостатки переменных окружения
- сложны в использовании, потому что, поскольку многие независимые программы нуждаются в информации, этот подход намного удобнее. они видны (удаляемые, настраиваемые) из любого места. Если я установлю новую программу, которая опирается на переменные окружающей среды, они будут топать по моим существующим?
Мое мнение
- использует аргументы командной строки для тех аргументов, которые, скорее всего, для каждого индивидуального вызова программы (т. е. n для программы, которая вычисляет n!) [/ g2]
- использует конфигурационные файлы для аргументов, которые пользователь может разумно изменить, но не очень часто (т. е. размер отображения когда окно всплывает)
- экономно использует переменные среды - предпочтительно только для аргументов, которые, как ожидается, не будут меняться (т. е. местоположение интерпретатора Python)
- ваша точка
They are global and accessible from anywhere, which is less elegant from architectural point of view, but limits the amount of codeнапоминает мне об обоснованиях использования глобальных переменных;)
. Мои шрамы из первых рук испытывают ужасы перегрузки окружающей среды
- две программы, которые нам нужны на работе, которая не может одновременно работать на одном компьютере из-за экологических столкновений
- нескольких версий программ с тем же именем но разные ошибки - часами целую мастерскую на колени, потому что расположение программы было вытащено из окружающей среды и было (тихо, тонко) неправильно.
2 ) Ограничения
Если бы я нажимал пределы того, что может удерживать командная строка, или то, что может обрабатывать среда, я бы реорганизовал немедленно.
Я использовал JSON в прошлое для приложения с командной строкой, для которого потребовалось много параметров. Было очень удобно использовать словари и списки, а также строки и номера. Приложение заняло всего несколько аргументов командной строки, одним из которых было расположение файла JSON.
Преимущества этого подхода
- не должны были писать много (болезненный) код для взаимодействия с библиотекой CLI - это может быть болью, чтобы получить много из общих библиотек для принудительного применения сложных ограничений («сложным» я имею в виду более сложным, чем проверка определенного ключа или чередование между набором ключей).
- не нужно беспокоиться о требованиях к библиотекам CLI для порядок аргументов - просто используйте объект JSON!
- легко представить сложные данные (ответы
What won't fit into command line parameters?), такие как списки - , простые в использовании данные из других приложений - оба создавать и анализировать программно
- легко для размещения будущих расширений
Примечание. Я хочу отличить это от подхода .config-file - это не для хранения пользовательская конфигурация. Может быть, я должен назвать это «параметром командной строки», потому что я использую его для программы, для которой требуется множество значений, которые не подходят хорошо в командной строке.
3 ) Переносимость решения: я не очень разбираюсь в различиях между Mac, ПК и Linux в отношении переменных окружения и аргументов командной строки, но могу вам сказать:
- все три имеют поддержку переменных среды
- , все они поддерживают аргументы командной строки
Да, я знаю - это было не очень полезно. Прости. Но ключевым моментом является то, что вы можете ожидать, что разумное решение будет переносимым, хотя вы определенно хотите проверить это для своих программ (например, являются ли аргументы командной строки аргументами с учетом регистра на любых платформах? На всех платформах? Я не знаю ).
Одна последняя точка:
Как отметил Томаш, это не имеет значения для большинства приложений, в которых были получены параметры.
-
1Благодарю вас, Мэтт. Это своего рода мнение, которое я искал. Наиболее важным вашим советом является использование переменных среды для описания среды исполнения, которое практически не меняется, и cmd-файл для фактического выполнения простейших / сложных аргументов. Очень рационально, спасибо. Обратите внимание, что вы можете использовать «локальные» переменные среды, которые могут испортить дочерние процессы. Это очень похоже на передачу аргументов командной строки, за исключением того, что Раймонд указал на ответ Томаша. – Janusz Lenar 29 September 2011 в 12:23
-
2Очень хороший ответ! Что касается недостатка, что переменные окружения могут быть изменены из любого места: существует также возможность локально устанавливать переменные среды из сценария запуска (например, Bash или Batch script) для приложения. В этом случае может быть системное значение по умолчанию, но приложение может при необходимости изменить значение по умолчанию на пользовательское значение. Что ты думаешь по этому поводу? – Lii 7 July 2015 в 11:59
-
3Есть ли какие-либо плюсы и минусы при рассмотрении вопроса о том, как пройти секреты / учетные данные? – iamyojimbo 15 November 2016 в 01:07
Я думаю, что на этот вопрос уже довольно хорошо ответил, но я чувствую, что он заслуживает обновления 2018 года. Я чувствую, что неизменное преимущество экологических переменных заключается в том, что они обычно требуют меньше котельного табличного кода для работы. Это делает более понятным код. Однако серьезным недостатком является то, что они удаляют слои изоляции из разных приложений, работающих на одной машине. Я думаю, что именно здесь Докер действительно сияет. Мой любимый шаблон дизайна - исключительно использовать переменные среды и запускать приложение внутри контейнера Docker. Это устраняет проблему изоляции.
Вы должны абстрагировать параметры чтения с помощью шаблона Strategy . Создайте абстракцию с именем ConfigurationSource, имеющую метод readConfig(key) -> value (или возвращающий некоторый объект / структуру Configuration) со следующими реализациями:
-
CommandLineConfigurationSource -
EnvironmentVariableConfigurationSource -
WindowsFileConfigurationSource- загрузка из файла конфигурации изC:/Document and settings... -
WindowsRegistryConfigurationSource -
NetworkConfigrationSource -
UnixFileConfigurationSource- - загрузка из файла конфигурации из/home/user/... -
DefaultConfigurationSource- значения по умолчанию - ...
Вы также можете использовать Цепь ответственности для привязки источников в различных конфигурациях, таких как: если аргумент командной строки не указан, попробуйте переменную окружения, и если все остальное не выполнено, верните defauls.
Ad 1. Этот подход не только позволяет абстрагировать конфигурацию чтения, но вы можете легко изменить базовый механизм без какого-либо влияния на код клиента. Кроме того, вы можете использовать сразу несколько источников, отступать или собирать конфигурацию из разных источников.
Ad 2. Просто выберите, какая из реализаций подходит. Конечно, некоторые записи конфигурации не подходят, например, к аргументам командной строки.
Объявление 3. Если некоторые реализации не переносимы, имейте два, один молча игнорируемый / пропущенный, если он не подходит для данной системы.
-
1Спасибо, это вообще хорошая идея. Но это не помогает решить, использовать ли среду или командную строку. Разработка некоторых ваших конфигурационных записей в Ad.2. не подходит для аргументов командной строки . Что не поместится в строку? Если это не подходит, оно должно быть, вероятно, передано косвенно в виде файла, не так ли? – Janusz Lenar 16 September 2011 в 12:01
-
2Я хочу сказать: не заставляйте пользователя использовать параметры командной строки или . Будьте гибкими (и тем не менее сохраните основной код). Я считаю, что конфигурационный файл является лучшим местом для хранения конфигурации (он может быть произвольно длинным, содержать комментарии и т. Д.), Однако иногда полезно переопределить конфигурацию файла с помощью параметров командной строки. Что не поместится в параметры командной строки? Если вам нужно пройти несколько путей к файлу, это, вероятно, будет работать, но никто не любит чрезмерно длинные командные строки. – Tomasz Nurkiewicz 16 September 2011 в 12:06
-
3Конфигурационный файл лучше всего подходит для аргументов - это ценное мнение и поддержка комментариев - хорошая причина для его использования, спасибо. Если вы используете переменные среды при запуске приложения из пакетного скрипта, вы можете получить очень читаемую форму, используя
remиset. Если вы создаете процесс, вы простоsetenvхотите, прежде чемspawnl-инг. Это удобно, читаемо и гибко. Почему вы используете .config вместо среды? Это вопрос. – Janusz Lenar 16 September 2011 в 12:26 -
4– Raymond Chen 24 September 2011 в 15:18
-
5Спасибо, @ Раймонд. Объем переменных окружения опасно широк. Хорошая точка зрения. – Janusz Lenar 29 September 2011 в 08:07