Сдруживаем Python и Bash: библиотеки smart-env и python-shell

То лаконичнее и удобнее использовать чистый shell скрипт, а не Python.

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

И потом парсить .output в python? Красиво получится, да. А если вместо предложенного варианта не использовать однострочник с list comprehension, то можно написать читаемый, понятный код.

Да, можно, но в примере с циклом Вам нужно будет прочитать больше строк кода, выполняющих то же самое, что 1-2 строчки с использованием Shell.

Библиотека должна одинаково хорошо и легко работать с любой Bash-командой (ls — это просто пример, не более), вплоть до сложных конструкций и последовательностей команд. И она будет это делать в будущих релизах.

Или, если нужно писать на питоне — выучить какой-нибудь курс «питон за 10 уроков». Писать на питоне, и испытывать сложности с dictionary… Не нужно даже пытаться.

Скорее всего, человек, которому поставлена задача смигрировать скрипты на Python, и так изучит его подобным образом. Но речь не о том, есть ли сложности со словарями или нет — вынуть переменную по ключу сможет любой хелловордщик. Если скрипт не предполагает интерпретацию значений из переменных окружения, то smart-env, вероятно, не даст ощутимой выгоды (кроме, может, как конфигурационный объект). Но с тем же успехом можно назвать Openstack «излишней сложностью», если рассматривать его в качестве площадки для поднятия вордпрессового блога на локалхосте.

Поставленную задачу (запуск процессов с параметрами и получение результатов) этот код выполняет. Зачем усложнять?

Посмотрим на Ваш пример с точки зрения качества кода:
1. Название команды само по себе не является аргументом, который следует класть в args. В Вашем примере объект, вызывающий RunMeSimple(), частично осведомлен о внутренностях вызываемой функции — явный признак того, что код надо переписать.
2. Функция возвращает кортеж из четырех (!) значений. Серьёзно? Получается, вызывающему надо будет ещё и правильно распилить полученный кортеж по переменным и, не дай Бог, не поменять stdout и stderr местами и потом гадать, почему docker ps сыпет текст в поток ошибок.
3. Возможно, я и излишне придрался к конкретному примеру, но, опять-таки, пока проект — это пара скриптов и десяток функций, то можно и subprocess дергать, а вот когда это будет мамонт на овер9000 строк — наверняка вспомните опыт других, но уже станет страшно даже чихнуть не в том месте, чтобы все не рухнуло.

Идея python-shell — это упрощение кода, а не усложнение. Ваш пример преобразовался бы в куда более понятное

cmd = Shell.mycommand(*args, env=env_from_somewhere, cwd='.')
# и где-то ниже, непосредственно там, где это нужно по логике программы
passToSomeFoo(cmd.output)
# и т.п.

причем даже без необходимости создавать под это отдельную функцию (в которой на 95.5% гарантированы копипасты блоков кода из аналогичных «функций-вызывалок»).

Вспомнилась фраза: «Это Си, тут Солнце выкатывают и закатывают вручную». Безусловно, можно продолжать городить кучи комбинаций Popen()+communicate()+<и т.д.> (втайне мечтая переехать на «новенький» 3.5 с 2.7, чтобы суметь в subprocess.run) и кушать кактус. Но зачем?

Если раньше это работало на bash — я бы хотел видеть (развидеть не смогу, знаю) ;)

Про JSON — это не портирование Bash, а новая возможность (хотя попытки ее применения, думаю, не новинка).
Про булевое значение: Вам никогда не приходилось интерпретировать значение переменной окружения на предмет того, True или не True?

# export DEBUG=True
# предположим, если переменная не выставлена, то считаем ее False
DEBUG = bool(os.environ.get('DEBUG'))

# export DEBUG=False
# export DEBUG=0
# и тут номер с невыставлением не проходит...
DEBUG = os.environ.get('DEBUG') not in ("False", "false", 0, None)  # красиво?

А теперь, согласно Вашей теории, «усложнённый» вариант:

# скажем, это наш config.py

from smart_env import ENV
ENV.enable_automatic_type_cast() 

DEBUG = ENV.DEBUG  # и весь парсинг уже сделан за нас - в конфиге только полезная информация!

Надеюсь, я ответил на Ваш вопрос. :)

Параметр "-p" не относится к читабельности и багам. Если ваш скрипт предусматривает его использование — используйте. Библиотеки из поста тут ни при чём — это был просто пример.