LINUX.ORG.RU

[python] Что заменяет source функцию bash

 


0

3

Вот опять та же проблема: пишу новый скрипт на Python и хочу считывать настройки (значения переменных) с файла. У bash делаю source <имя файла>, а как сделать у python?

Всегда обхожу эту проблему так: пишу баш срипт с source <Файл настроек>, а потом запускаю питон срипт с длинным перечнем параметров и разгребанием этих параметров уже в самом скрипте по переменным...


Ответ на: комментарий от anonymous

>>А у меня и так все ок без всякого ConfigParsera.

Я его тоже раньше не воспринимал, а оказалась неплохая штука.

Все что я думаю по эьлму поводу http://a-iv.ru/pyart/igl.pdf Если уж хочется каких то наворотов по сравнению с exec, то наверное ничего более выскоуровнего придумать невозможно.

А мы, уважаемый не-лиспер, уже года 4 тут сидим, и нам совершенно это не надо:)

Мы... т.е. у вас шизофрения? Это конечно затрудняет регистрацию;-) На самом деле ИМНО зря - анонимусов много, народ зачастую буйный, и общацца с ними бывает сложно.

AIv ★★★★★
()
Ответ на: комментарий от AIv

>Все что я думаю по эьлму поводу http://a-iv.ru/pyart/igl.pdf Если уж хочется каких то наворотов по сравнению с exec, то наверное ничего более выскоуровнего придумать невозможно.

Это разные вещи. И вообще этот IGL, имхо, жутковат. Да и главное, что ConfigParser лежит в стандартной библиотеке питона, а значит он есть везде. А это большой плюс при распространении программы.

Хотя, опять же, важно что у тебя за конфиг. В случае сложных вложенных конструкций может понадобиться и json, и прочее.

Мы... т.е. у вас шизофрения?

Можешь считать, что я «монарх, редактор или больной солитёром» (с) Марк Твен.

На самом деле ИМНО зря - анонимусов много, народ зачастую буйный, и общацца с ними бывает сложно.

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

anonymous
()
Ответ на: комментарий от shylent

Далее, по логике, я перед исполнением ломаю класс Popen. И начинается череда итераций дырка -> её затыкание. Как защищающаяся сторона, я изначально в проигрышной ситуации, да.

Вообще с песочницами в CPython всё туго, соглашусь.

baverman ★★★
()
Ответ на: комментарий от baverman

Как защищающаяся сторона, я изначально в проигрышной ситуации, да.

Вообще с песочницами в CPython всё туго, соглашусь.

Ну да, именно так. Ведь даже если «сломать» весь потенциально опасный функционал, никто не мешает мне написать в конфиге что-то типа:

<большое_число> ** <большое_число>
вы же не хотите ждать, пока это все посчитается?

Более того, если я не заблуждаюсь, то эту операцию вы не сможете прибить по таймауту из отдельного треда. Почему?

>>> dis.dis(lambda : a ** a)
  2           0 LOAD_GLOBAL              0 (a)
              3 LOAD_GLOBAL              0 (a)
              6 BINARY_POWER        
              7 RETURN_VALUE
Шанс переключиться на другой тред появится только когда BINARY_POWER будет уже полностью выполнен. (могу ошибаться - конкретно этот пример не проверял).

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

p.s. без всякого негатива лично в ваш адрес

shylent
()
Ответ на: комментарий от shylent

Ну согласен, «можно придумать защиту от дурака, но только от неизобретательного»;-)

Скомпилить текстовый конфиг gcc и протащить через Свиг?;-))))

Тем не менее, насчет import остаюсь при своем мнении.

AIv ★★★★★
()
Ответ на: комментарий от AIv

> Скомпилить текстовый конфиг gcc и протащить через Свиг?

Такие вещи, как и некоторые другие, следует делать в полном уединении, - чтобы никто не увидел. Стыдно же потом будет.

Тем не менее, насчет import остаюсь при своем мнении.


Ничего страшного. Писать плохой код - неотъемлемое право любого программиста.

shylent
()
Ответ на: комментарий от shylent

> Такие вещи, как и некоторые другие, следует делать в полном уединении...

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

Ничего страшного. Писать плохой код - неотъемлемое право любого программиста.

Да уж не оправдывайтесь, я Вас ни в чем не обвиняю, пишите как хотите;-)

AIv ★★★★★
()
Ответ на: комментарий от shylent

И что б расставить вся умляуты - вот у меня конфиг

a, b, c = 1, 2 ,3

Я хочу превратить его в словарь вида {'a':1,'b':2,'c':3}, причем хочу ззять его из строго определенного файла лежащего в строго определенной директории, в простйешем случае это скажем файл ~/.myapplication Сравните-ка число строк с реализацией через import и через execfile, а потом в утешение можете перечитать чего Вы там писали выше про право на плохой код?;-)

AIv ★★★★★
()
Ответ на: комментарий от AIv

Я хочу превратить его в словарь вида {'a':1,'b':2,'c':3}, причем хочу ззять его из строго определенного файла лежащего в строго определенной директории, в простйешем случае это скажем файл ~/.myapplication

import os.path
import imp

conf_file = '~/.myapplication'
conf_module = imp.load_source('config', conf_file)
to_dict = ['a', 'b', 'c']
print dict(map(lambda x : (x, getattr(conf_module, x)), to_dict))

anonymous
()
Ответ на: комментарий от anonymous

Да что Вы говорите, правда что ль?;-))))

Ну тогда сравните с

D={}; execfile( '~/.myapplication', D )

и перестаньте уже морочить людям голову.

AIv ★★★★★
()
Ответ на: комментарий от AIv

>А вариант когда имена ключей заранее не известны слабо предложить?;-)

А как вы без имён ключей превратите a, b, c = 1, 2, 3 в dict?

anonymous
()
Ответ на: комментарий от anonymous

>А как вы без имён ключей превратите a, b, c = 1, 2, 3 в dict?

Уточню - ваш вариант работает только тогда, когда вам всё надо положить в отдельный dict (в вашем примере - D). Достаточно иметь конфиг чуть-чуть сложнее - и всё пролетает.

anonymous
()
Ответ на: комментарий от AIv

>Ну тогда сравните с

D={}; execfile( '~/.myapplication', D )

Ну у меня лишний импорт os.path, например. Я забыл его убрать. И вообще, к чему экономить на строках кода в таких масштабах?

anonymous
()
Ответ на: комментарий от anonymous

Если они лежат в модуле, то есть ф-я dir(). С execfile вообще проблем нет. Лишние ключи как правило в словаре не мешают. Ну ка пример чуть более сложного конфига, к-й в Вашем случае с импорт работает а моем нет???

Вы читали первый пост того кто эту темпу поднял? Он вообще bash-ом все разбирал, о каких сложных конфигах Вы тут говорите???

Вместо map тут лучше взять гененратор, лаконичнее. load_source не понимает путей с тильдой, как и все питоновские ф-ии, надо было сделать expanduser. В общем где то между тройкой и четверкой Вы сейчас... ;-)

AIv ★★★★★
()
Ответ на: комментарий от anonymous

На строках кода надо экономить ВСЕГДА. И дел не в числе строк кода, а в числе действий, Вы прадва разницы не видите????

AIv ★★★★★
()
Ответ на: комментарий от AIv

>На строках кода надо экономить ВСЕГДА. И дел не в числе строк кода, а в числе действий, Вы прадва разницы не видите????

не в ущерб ясности, скорости.

chinarulezzz ★★
()
Ответ на: комментарий от chinarulezzz

> не в ущерб ясности, скорости.

С этим я не спорю;-)))) Но напр после рефракторинга ядро CAS рабирющее выражение в дереов у меня ужалось с 600 строк до 60ти. И при этом ясность (и возможность добавления новых классов) существенно выросли. Так что зачастую лаконичность и ясность являются синонимами.

AIv ★★★★★
()
Ответ на: комментарий от AIv

>Ну ка пример чуть более сложного конфига, к-й в Вашем случае с импорт работает а моем нет???

Пример - надо создать два dict-а. А не один. В обоих случаях надо что-то делать с исходным модулем, либо с вашим диктом. А если не видно разницы...

Вместо map тут лучше взять гененратор, лаконичнее.

Я знаю. Естественно, в реальном проекте я так не пишу.

load_source не понимает путей с тильдой, как и все питоновские ф-ии, надо было сделать expanduser.

А вот это не знал, впрочем, проверял через полный путь у себя.

anonymous
()
Ответ на: комментарий от anonymous

Разницы две - Ваш случай подразумевает танцы с бубном вокруг модуля imp + необходимость как то преобразовывать результат, даже если нужен один общий словарь (что практически всегда).

Формально exefile ничем от load_source не отличается, только .pyc не создает (что ИМНО в данном случае +, поскольку .pyc может создать несколько неожиданных праблов из за прав доступа, напр если первый запуск был от рута).

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

AIv ★★★★★
()
Ответ на: комментарий от sdh

Лучше создать новую тему, кроме меня навряд ли кто увидит это сообщение.

socketserver не пробовал. Но по описанию интерфейса — достаточно простая и подходящая вещь, тем более если не надо обслуживать множество клиентов одновременно.

baverman ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.