Comments 93
По-моему лучше оставить close() для каких-нибудь специальных нужд и писать просто:
with open("/home/khim/helloworld", "w") as gogo:Необходимость этого доказывает ваш второй пример где вы умудрились закрыть файл — и это в статье со словами Запомните! Любое открытие файла должно сопровождаться последующим закрытием с помощью этого метода…
gogo.write("Hello, world!\n")
Думаю не лишним будет сказать, что with поддерживается только с версии 2.5.
Python 2.5 появился больше двух лет назад. Никому же не приходит в голову говорить что bash поддерживает [[ и (( только с версии 2.0?
Люди еще РНР4 используют ) Так что небольшое предупреждение думаю не повредит.
во всяких тырпрайз дистрах (RHEL/Debian) пока еще 2.4
Ну мне например приходится на python 2.3 писать регулярно, но это скорее вырожденный случай, Вы правы конечно.
Я пытался использовать Python для таких целей, но быстро пришел к мнению, что это извращение. Все-таки shell со всеми своими кривостями удобнее для многих вещей. Сравните:
host l2tp.corbina.ru | egrep -o -m 1 '([0-9]+\.){3}[0-9]+'
host l2tp.corbina.ru | sed -r -n '2s/.+\ address\ //p'
host l2tp.corbina.ru | awk '/address/ {print $4; exit}'
host l2tp.corbina.ru | egrep -o -m 1 '([0-9]+\.){3}[0-9]+'
host l2tp.corbina.ru | sed -r -n '2s/.+\ address\ //p'
host l2tp.corbina.ru | awk '/address/ {print $4; exit}'
s/shell/shell со стандартными программами/
Python не замена Shell…
А bash!=sh
Ой, а кто такое читать умеет?
Я уж не говорю о писать
Я уж не говорю о писать
Писать такое как раз нормально. Главное — в файлах не сохранять, а то так и до скриптов с тысячу строк (в которых потом чёрт ногу сломает) недалеко.
Python во многом потому и составляет конкуренцию — потому что код на нем изящен и легко читается.
UFO just landed and posted this here
у вы же читать на русском умеете. А человек, который знает испанский, но не знает русский, умеет читать по испански. А китайский текст вам вообще тарабарщиной с другой грамматикой покажется. Не все языки похожи, но это не значит, что непохожие хуже.
П.С. Для меня — это вполне читабельный вид.
П.С. Для меня — это вполне читабельный вид.
Странное дело — для меня код на C/C++, Java, Python, Ruby, Perl, PHP, JavaScript читабелен, а приведенное выше — нет. Появляется вполне логичный вопрос — а кому такое читабельно?
Развивая вашу аналогию — отправляясь в Европу не стоит особо рассчитывать на знания корейского.
Развивая вашу аналогию — отправляясь в Европу не стоит особо рассчитывать на знания корейского.
Там не читабелен только первый вариант из-за регулярки и относительно редко используемых опций grep, которые я перед написанием посмотрел в man. Варианты на sed и awk тривиальны и понятны любому, кто с ними как-то знаком. Вы тоже не родились со знанием C, Java или Perl.
Регулярки — это вообще не считается, потому что они используются в большинстве языков.
И относительно аналогии, китайский слабо распространен среди не китайцев, но китайцев достаточно много, чтобы говорить о большом количестве людей понимающих китайский)
И относительно аналогии, китайский слабо распространен среди не китайцев, но китайцев достаточно много, чтобы говорить о большом количестве людей понимающих китайский)
Кстати, вы назвали все языки принадлежащие только к одному виду языков. А где же пролог, хаскель, лисп, f#, эрланг и языки других видов?)
Ага, языки одного вида (кроме JavaScript, но мы о нем тактично промолчим).
Случилось так что C/C++, Python, Ruby, Perl я использую для автоматизации процессов в Unix системах. Ну не встречаются мне скрипты на lisp, haskell, io, lua, хоть и интересуюсь. А если я попробую их использовать заказчики не поймут — кому потом систему поддерживать, дорабатывать?
Случилось так что C/C++, Python, Ruby, Perl я использую для автоматизации процессов в Unix системах. Ну не встречаются мне скрипты на lisp, haskell, io, lua, хоть и интересуюсь. А если я попробую их использовать заказчики не поймут — кому потом систему поддерживать, дорабатывать?
Человеку, который не знает руби, код на руби покажется таким же не читаемым, как вам код на bash. А если брать код bash без синтаксиса awk,sed итп., то он как бы совсем легко читается.
Мне не кажется нечитаемым код на bash. Я просто не хочу его читать. Он мне по просту не нравится (как и php, а также C++ местами).
Человек знакомый с одним из языков ветки легко переходит на другой. Bash для него тоже не составляет труда.
Видать в этих землях полно поклонников недоязыков… минусуют.
BASH — отличная штука, но как язык программирования полный отстой.
Да, не ослышались — отстой. Что за манеры — ковыряться дубинкой в носу?
Повторюсь еще раз — посмотрите на другие языки! В мире софта и так полно кривых решений. Да идеальное не создать, но можно хотя бы приблизится к идеалу!
А как будете минусовать хоть коментарий оставьте, мне действительно интересно мнение.
BASH — отличная штука, но как язык программирования полный отстой.
Да, не ослышались — отстой. Что за манеры — ковыряться дубинкой в носу?
Повторюсь еще раз — посмотрите на другие языки! В мире софта и так полно кривых решений. Да идеальное не создать, но можно хотя бы приблизится к идеалу!
А как будете минусовать хоть коментарий оставьте, мне действительно интересно мнение.
Согласен, Bash как язык программирования полный отстой. Я его толком не знаю и писать на нем меня ломает. Но задачи типа связывания каналом пары программ и простой фильтрации текста с помощью стандартных shell инструментов решаются проще. И в статье как раз не показано преимуществ. Дубасить Врагов Отечества надо дубинкой, а ковырятся в носу пальцами =)
Не надо приводить все языки к одному виду. Парадигм программирования очень много(аспектное, объектное, событийное, командное итп), и если у языка непривычная, или неудобная для какого-то, пусть даже и большого количества, людей структура, то это не делает его хуже для какого-то, пусть даже и маленького количества, людей, которым он нравится.
П.С. Правда из коммандных языков мне нравится больше tcl, но он довольно сильно похож на bash.
П.С. Правда из коммандных языков мне нравится больше tcl, но он довольно сильно похож на bash.
Да я не привожу… Просто я вижу язык на котором можно создавать страшные вещи. Язык развивавшийся стихийно, пытающийся поддерживать обратную совместимоть. Язык переросший первоначальную задачу.
Это делает язык хуже для людей сталкивающихся с творчеством людей не знающих меры, а может просто знающих только один язык.
Это делает язык хуже для людей сталкивающихся с творчеством людей не знающих меры, а может просто знающих только один язык.
Где тут развитие, большинству его возможностей почти двадцать лет. Синтаксис регулярных выражений обычный перловский. awk — си-подобный язык, основные возможности осваиваются за час. sed — тоже не шибко сложнее. Перенаправление вывода одной комманды в другую — эта вещь знакомая каждому пользователю юникс-подобной системы.
И у этого языка есть один огромнейший плюс. Он приучает не изобретать велосипеды там где они не нужны.
И у этого языка есть один огромнейший плюс. Он приучает не изобретать велосипеды там где они не нужны.
Имхо, не изобретать велосипеды это использовать библиотеки:
— python pypi
— ruby gems
— perl cpan
есть это под bash?
Именно библиотеки определяют возможность использования языка.
— Вы импортируете / экспортируете данные из csv, xml, odt?
— Производите математические рассчеты?
— Строите графики?
— Создаете GUI с Gtk, Qt (я помню о Tcl, вопрос для bash)?
— А как вы работаете с RPC / SOAP?
Вам не кажется что мы рассматриваем разные задачи?
— python pypi
— ruby gems
— perl cpan
есть это под bash?
Именно библиотеки определяют возможность использования языка.
— Вы импортируете / экспортируете данные из csv, xml, odt?
— Производите математические рассчеты?
— Строите графики?
— Создаете GUI с Gtk, Qt (я помню о Tcl, вопрос для bash)?
— А как вы работаете с RPC / SOAP?
Вам не кажется что мы рассматриваем разные задачи?
Библиотека bash — это /bin && /usr/bin && /sbin && /usr/sbin
Там есть много чего интересного)
— Данные awk,sed и прочее
— www.linux.org/apps/all/Scientific/Math.html выбираем любую, и используем. Они большинство под gpl
— Графики plotutils
— bash скрипты, как бы предназначены для запуска в среде bash, но если неймется, то можно использовать zenity и dialog
— rpc запросы если только через netcat слать
Похоже на то. В начале мы рассматривали вопрос написания служебных скриптов.
Там есть много чего интересного)
— Данные awk,sed и прочее
— www.linux.org/apps/all/Scientific/Math.html выбираем любую, и используем. Они большинство под gpl
— Графики plotutils
— bash скрипты, как бы предназначены для запуска в среде bash, но если неймется, то можно использовать zenity и dialog
— rpc запросы если только через netcat слать
Похоже на то. В начале мы рассматривали вопрос написания служебных скриптов.
Эм… вы не фанатик случайно? Ручной парсинг… брр.
Создается впечатление будто вы готовы переписать все на bash.
Ключевой для меня момент:
>> BASH — отличная штука, но как язык программирования полный отстой.
И если мне нужно узнать текущую директорию я воспользуюсь
а не
Но при создании приложения я воспользуюсь языком программирования. А вы приложения создавали?
Создается впечатление будто вы готовы переписать все на bash.
Ключевой для меня момент:
>> BASH — отличная штука, но как язык программирования полный отстой.
И если мне нужно узнать текущую директорию я воспользуюсь
$ pwd
а не
$ python -c "import os; print os.path.abspath(os.curdir)"
Но при создании приложения я воспользуюсь языком программирования. А вы приложения создавали?
Не обязательно ручной парсинг. И я не говорил, что я буду писать всё на bash. Я говорил, что он по возможностям не уступает другим языкам. Мне кажется, что вы смешиваете понятия языка программирования, и языка программирования на котором пишутся десктопные приложения.
Вы сами написали ответ на импорт / экспорт csv, xml, odt — awk, sed и прочее — вероятно таки руками.
А мне кажется вы не понимаете о чем я говорю. Потрудитесть прочесть и иные ветки.
habrahabr.ru/blogs/python/47474/#comment_1219134
habrahabr.ru/blogs/python/47474/#comment_1220000
habrahabr.ru/blogs/python/47474/#comment_1221499
Еще — что это за «язык программирования на котором пишутся десктопные приложения» у вас есть опыт программирования? Вы понамаете о чем говорите? Или только лабы умеете писать?
А мне кажется вы не понимаете о чем я говорю. Потрудитесть прочесть и иные ветки.
habrahabr.ru/blogs/python/47474/#comment_1219134
habrahabr.ru/blogs/python/47474/#comment_1220000
habrahabr.ru/blogs/python/47474/#comment_1221499
Еще — что это за «язык программирования на котором пишутся десктопные приложения» у вас есть опыт программирования? Вы понамаете о чем говорите? Или только лабы умеете писать?
Я прекращаю дискуссию ибо бред
Shell — это shell. При наборе команд в командной строке важна лаконичность. А вот в скриптах (особенно больших) уже важнее читаемость…
Речь идёт не о замене командных строк баша, а о том, что питоновские скрипты вполне заменяют шеловские обычные скрипты. Автор как раз это и показывал в статье.
Разве вам не приходилось видеть установочные скрипты на многие тысячи строк?
Речь о том, что можно реализовать их на Питоне и они будут изящными. Причём очень важный момент: в них можно использовать всю мощь Питона и задействовать возможности для использования которых в традиционных скриптах пришлось бы писать Си-шные утилитки.
Разве вам не приходилось видеть установочные скрипты на многие тысячи строк?
Речь о том, что можно реализовать их на Питоне и они будут изящными. Причём очень важный момент: в них можно использовать всю мощь Питона и задействовать возможности для использования которых в традиционных скриптах пришлось бы писать Си-шные утилитки.
Я с вами согласен конечно. Я тоже что-то пишу на Python, что-то — на Bash. Вопрос в выборе инструмента, и я как раз ожидал увидеть примеры, когда Python лучше. В статье код довольно не интересный и не показывает особенностей Python. Так можно написать на чем угодно, а на Bash + sed + grep + awk получается проще.
Пример из жизни (прям сейчас работаю) Guard:
— стартует при запуске системы
— мониторит логи, принимает RPC-запросы, все это парсит
— останавливает, запускает процесы
— конфигируруемая логика событий
— обо всем этом пишет логи
Для решения задачи каждый использует свой набор инструментов. Я вот Python / Ruby / Perl — обычно выбор определяют требования заказчика и библиотеки.
— стартует при запуске системы
— мониторит логи, принимает RPC-запросы, все это парсит
— останавливает, запускает процесы
— конфигируруемая логика событий
— обо всем этом пишет логи
Для решения задачи каждый использует свой набор инструментов. Я вот Python / Ruby / Perl — обычно выбор определяют требования заказчика и библиотеки.
извращение. гланды через ж? =\
Что-то много букаф. Второй скрипт:
import os, re, sys, commands
r = re.findall(r'address\s+([.\d]+)', commands.getoutput('host '+sys.argv[1]), re.MULTILINE)
print 'Addr:', r[0] if len® else ''
Первый скрипт:
open("/home/username/goo",«w»).write('GOO')
Файл вполне успешно закроется сборщиком мусора, и в однострочниках его закрывать — пустая трата времени.
Если все же есть опасения, то with поможет. Правда для 2.5 придется написать from __future__ import with_statement
Для однострочников может питон и не рулит, но если нужно сделать что-то достаточно сложное — то тут он уже уделывает баш, конечно.
import os, re, sys, commands
r = re.findall(r'address\s+([.\d]+)', commands.getoutput('host '+sys.argv[1]), re.MULTILINE)
print 'Addr:', r[0] if len® else ''
Первый скрипт:
open("/home/username/goo",«w»).write('GOO')
Файл вполне успешно закроется сборщиком мусора, и в однострочниках его закрывать — пустая трата времени.
Если все же есть опасения, то with поможет. Правда для 2.5 придется написать from __future__ import with_statement
Для однострочников может питон и не рулит, но если нужно сделать что-то достаточно сложное — то тут он уже уделывает баш, конечно.
Я уверен, что из тех кто прочёл этот пост, какой-то процент заинтересуется языком. Ещё небольшой процент от них его полюбит и начнёт использовать. И вот они уже к тому моменту сами с лёгкостью будут писать подобные выражения-монстры.
Но начинать-то нужно с малого ;)
Вот если бы топик назывался «Как на питоне определить ip-адрес корбины», то тогда, несомненно, можно было подвергнуть разгромной критике всё вышенаписанное.
А я позволю себе критику но небольшую. Вот тут
Но начинать-то нужно с малого ;)
Вот если бы топик назывался «Как на питоне определить ip-адрес корбины», то тогда, несомненно, можно было подвергнуть разгромной критике всё вышенаписанное.
А я позволю себе критику но небольшую. Вот тут
([\d]+)\.([\d]+)\.([\d]+)\.([\d]+) всё же можно и квантификатор {1,4} себе позволить для облегчения читаемости :)import os, re, sys, commands
r = re.findall(r'address\s+([.\d]+)', commands.getoutput('host '+sys.argv[1]), re.MULTILINE)
print 'Addr:', r[0] if len® else ''
Согласен, но я не ставил целью компактность :) Согласитесь, что написанное вами объяснить в двух строчках было бы куда сложнее.
listdir(path)Пишите уж тогда принадлежность к модулю
gogo.closeclose() метод, а не свойство — в питоне нельзя опускать скобки, если в функцию не передаются параметры.
hst != NoneТак не пишут:
Comparisons to singletons like None should always be done with
'is' or 'is not', never the equality operators.
PEP 8 — Style Guide for Python Code
А вообще же данная задача решается методом socket.gethostbyname(domain)
Раз уж vs bash, то может стоит перенести в блог Линукс для всех и добавить соответствующий тег.
Причем тут линукс? :)
У меня под Mac OS тоже bash.
Под win32 вообще, думаю вариант для тех кто не ставит себе cygwin.
У меня под Mac OS тоже bash.
Под win32 вообще, думаю вариант для тех кто не ставит себе cygwin.
Я знаю bash и Windows PowerShell, но теперь я использую для всего именно Питон.
Главное преимущество Питона: он МОЩНЕЕ чем просто язык сценариев; это полноценный язык программирования. Т.е. написать скрипт не труднее чем на баше, но если нужно можно добавить какую угодно функциональность. А для традиционных скриптов пришлось бы писать и использовать программу на Си.
Главное преимущество Питона: он МОЩНЕЕ чем просто язык сценариев; это полноценный язык программирования. Т.е. написать скрипт не труднее чем на баше, но если нужно можно добавить какую угодно функциональность. А для традиционных скриптов пришлось бы писать и использовать программу на Си.
Поясняю для минусующих:
Эта статья важна именно для Windows, потому, что там нет установленых по умолчанию bash и Windows PowerShell.
Эта статья важна именно для Windows, потому, что там нет установленых по умолчанию bash и Windows PowerShell.
Ну всё-таки сказать что писать скрипт не труднее чем на bash'е нельзя. На bash'е вы можете получить результат работы программы просто написав
а на Python'е это выглядит заметно сложнее. Но если вам нужно в программе не просто вызвать несколько файлов, но и закодировать какую-то логику, то Python — уже удобнее. И быстрее.
RESULT=$(host l2tp.corbina.ru)
а на Python'е это выглядит заметно сложнее. Но если вам нужно в программе не просто вызвать несколько файлов, но и закодировать какую-то логику, то Python — уже удобнее. И быстрее.
Для виндовс есть другие скриптовые языки (javascript/vbscript) — первичные (так сказать, заточенны под него), все остальное повторяю вторично.
Помню когда-то игрался подобным способом, и то что сильно не понравилось, так то что raw_input() не умеет автодополнения. Весьма напряжно при введении длинного пути к файлам и т.п.
С этим можно что-то сделать?
С этим можно что-то сделать?
Да, можно.
По моему скромному мнению вместо
#!/usr/bin/python
лучше писать
#!/usr/bin/env python
#!/usr/bin/python
лучше писать
#!/usr/bin/env python
сложные участки для шела(неудобные в написании и понимании на sh) типа коннекта к бд или коннект по телнету пишу на питоне и все эти кусочки потом срепляю sh-скриптами
Не убедили, такие операции делаю с помощью grep, sed, awk с закрытыми глазами, смысла изучать Питон админу пока что не вижу.
Пишите еще, интересно было бы почитать:
— сравнение скорости выполнения пакетных операций, вроде обработки регекспами файла в несколько тысяч строк
— обзор библиотек полезных в администрировании.
Пишите еще, интересно было бы почитать:
— сравнение скорости выполнения пакетных операций, вроде обработки регекспами файла в несколько тысяч строк
— обзор библиотек полезных в администрировании.
Вы правы насчет операций grep,sed и awk. Они действительно полезны, отлично работают, и для таких целей лучше использовать их. К тому же они чаще всего быстрее, как бы вы не оптимизировали Pyhton'овский код.
Но вот насчет смысла изучения Python, я бы посоветовал вам изменить свое мнение. Ваши возможности расширятся многократно, как только вы начнете его испозьзовать. И, как было сказано выше, при решении задач, которые сложнее, чем описанные примеры, Python идеально подходит.
Когда вы владеете обоими этими инструментами, работать значительно приятнее.
Но вот насчет смысла изучения Python, я бы посоветовал вам изменить свое мнение. Ваши возможности расширятся многократно, как только вы начнете его испозьзовать. И, как было сказано выше, при решении задач, которые сложнее, чем описанные примеры, Python идеально подходит.
Когда вы владеете обоими этими инструментами, работать значительно приятнее.
Сравнить бы скорости… Из питон-программ юзаю yum — это просто тренажер терпения. Первая ассоциация — программист, выпущенный на марафон.
А так, целью статьи было введение в общесистемные команды Питона?
А так, целью статьи было введение в общесистемные команды Питона?
Yum — это который менеджер пакетов? Вы считаете на sh быстрее?
По поводу скорости — тормозят обычно алгоритмы. В качестве примера — стандартный менеджер пакетов Gentoo emerge написан на Python, есть ускоренная версия и тоже на Python, но она шустрее поскольку кеширует некоторые моменты.
В большинстве случаев скорости Python хватает. Если же не будет хватать — определяем профайлером узкое место и реализуем на C. Это гуманее чем писать все на C. Чтобы убедится достаточно найти в доках создания расширений Python небольшой пример реализованный на C и на Python.
По поводу скорости — тормозят обычно алгоритмы. В качестве примера — стандартный менеджер пакетов Gentoo emerge написан на Python, есть ускоренная версия и тоже на Python, но она шустрее поскольку кеширует некоторые моменты.
В большинстве случаев скорости Python хватает. Если же не будет хватать — определяем профайлером узкое место и реализуем на C. Это гуманее чем писать все на C. Чтобы убедится достаточно найти в доках создания расширений Python небольшой пример реализованный на C и на Python.
Для Windows — Python спасает от написания bat-скриптов. Для *nix — сомнительно.
Автор зачем то питона ставит против баша. У каждого есть любимое блюдо, какоето блюдо на обед, на завтрак, на ужин.
Скрипты в пару десятков строк пишу на bash, чуть по сложнее на php — потому что мне так удобнее.
Автор молодец — приподнял завесу о том как написать консольный скрипт на любимом языке. Питон, перл, баш, рнр — только дело вкуса.
Скрипты в пару десятков строк пишу на bash, чуть по сложнее на php — потому что мне так удобнее.
Автор молодец — приподнял завесу о том как написать консольный скрипт на любимом языке. Питон, перл, баш, рнр — только дело вкуса.
О чём пост?
люблю пайтон, но если вы не на линуксе, а в произвольном юниксе, то питона может запросто не быть (на AIX нет)
а скрипты часто пишутся по принципу «написал в одном месте — использую везде»
а скрипты часто пишутся по принципу «написал в одном месте — использую везде»
как будто перла нету :)
очередной нуб открыл для себя скриптовой язык и хочет его теперь везде использовать :)
Python:
shell:
чувствуете разницу? Python — это всё таки больше ЯП, нежели хороший инструмент по автоматизации рутинных действий в операционной системе; а вот posix shell'ам в последнем равных нету, как ни старайтесь. Одни каналы чего стоят — на любом другом ЯП вы задолбаетесь создавать код, который должен тупо положить в переменную вывод результата работы внешней программы(а ведь для этого в другом ЯП придётся ещё создать системный вызов для запуска этой программы), пропущенный, к примеру, через grep или sed; в shell подобные действия осуществляются в одну строку. Каждой задаче — свой инструмент; и ни из python'а, ни из ruby(а что? тоже ведь скриптовый), хороший удобный shell не сделаешь, как ни старайся.
gogo = open ("/home/username/helloworld","w")
gogo.write("Hello, world!")
gogo.close()
shell:
echo "Hello, world!" >> /home/username/helloworld
чувствуете разницу? Python — это всё таки больше ЯП, нежели хороший инструмент по автоматизации рутинных действий в операционной системе; а вот posix shell'ам в последнем равных нету, как ни старайтесь. Одни каналы чего стоят — на любом другом ЯП вы задолбаетесь создавать код, который должен тупо положить в переменную вывод результата работы внешней программы(а ведь для этого в другом ЯП придётся ещё создать системный вызов для запуска этой программы), пропущенный, к примеру, через grep или sed; в shell подобные действия осуществляются в одну строку. Каждой задаче — свой инструмент; и ни из python'а, ни из ruby(а что? тоже ведь скриптовый), хороший удобный shell не сделаешь, как ни старайся.
а как на счёт, например,
new File("/home/ildar/tmp/file.txt4")<<«Hello, world!»
на groovy?
>на любом другом ЯП вы задолбаетесь создавать код, который должен тупо положить в переменную вывод результата работы внешней программы
def result = «uname -a».execute().text
new File("/home/ildar/tmp/file.txt4")<<«Hello, world!»
на groovy?
>на любом другом ЯП вы задолбаетесь создавать код, который должен тупо положить в переменную вывод результата работы внешней программы
def result = «uname -a».execute().text
э, не. Вы мою цитату на полуслове оборвали — у меня там дальше речь про конвейеры была — "… вывод <> внешней программы, _пропущенной_ <> через...". К примеру так:
имхо, нельзя приравнивать python и shell; ну разные у них задачи, раз-ны-е; поэтому для меня заголовок топика звучит как что-то вроде «C++ против HTML».
var="`cat file | grep <шаблон для вывода строк> | sed <шаблон для замены какого-либо одного текста на другой> | awk <печать определённых полей> | ... <и так далее>`"
я не сомневаюсь, наверняка в python'е тоже есть функционал (как и в любом другом нормальном ЯП) для работы с каналами (помню, даже как-то специально ковырялся в нём именно с целью разобраться, как их в нём можно использовать), но сомневаюсь, что это будет выглядеть столь лаконично и записываться в одну строку без лишних слов; опять же, в Вашем примере выше — целых два лишних слова — «execute().text»; так к чему плодить сущности без необходимости. Ну и ещё не стоит забывать, что в shell'е если переменная состоит только из цифр, то она, в зависимости от контекста, может использоваться и как численная переменная, и как текстовая — это _очень_ полезно и эффективно; afaik, в python'е без переконвертирования типов для этого не обойтись(хоть он и может использовать динамическую типизацию) — а это, опять же, лишние строки для вызова других методов для конвертирования данных.имхо, нельзя приравнивать python и shell; ну разные у них задачи, раз-ны-е; поэтому для меня заголовок топика звучит как что-то вроде «C++ против HTML».
Sign up to leave a comment.
Скрипты Python против Bash