Python для админа

вникай

Ну и вообще нужно ли знание ООП админу или девопсу?

Я думаю нет. Но пригодится может конечно. Да и в ООП нет ничего сложного.

Ну и вообще нужно ли знание ООП админу или девопсу?

нет.

Ну и вообще нужно ли знание ООП админу или девопсу?

Нужно. На уровне «понимаю что примерно тут происходит». До этого уровня дойти вовсе не сложно

Есть годная книжка Python в системном администрировании UNIX и Linux - советую глянуть, там есть что подчерпнуть.

ООП скорее всего понадобится, тем более что в питоне оно такое лайтовое.

Ну и вообще нужно ли знание ООП админу или девопсу?

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

Ну и вообще нужно ли знание ООП админу или девопсу?

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

Чисто по практической части - рекомендую глянуть ещё сюда: https://natenka.gitbooks.io/pyneng/content/ + там вроде был курс с задачками.

Читаю, вникаю, вроде бы все понятно, но потом застрял на главе посвященной ООП

Официальный туториал недавно читал. Та же фигня. Ощущение, словно глава про ООП написана каким-то извращенцем-дислексиком

Зачем тебе ООП - это модно? Вроде нет.

Но просто в качестве замены bash-а уже стоит учить Python, даже не доходя до объектов.

знание ООП админу или девопсу

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

ООП - это не магия, это способ структурирования кода (и мыслей). Если твои задачи выходят за рамки написания однострочников - то оно нужно.

Если не выходят, то сначала нужно выйти, а потом оно все равно станет нужно.

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

Конечно это будет не совсем то «ООП», которое у классических программистов, но вряд ли в твоей книжке сильно глубоко ныряют в эту тему. А как раз базовые понятия и принципы надо знать.

нужно. хотя бы для того, чтобы читать и понимать что происходит. а писать код - не админское дело

http://younglinux.info/oopython.php тут достаточно для понимания.

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

да чего там учить то в Питоне, особенно если для админских нужд

Админу знание ООП скорее всего не очень нужно, тут и простые портянки в процедурном стиле сгодятся. Но для общего развития познакомиться с тематикой ООП стоит.

зачем админу python, если дофига вещей работает на ruby?

Админу в вакууме не знаю, мне - нужно.

Как раз пилю на fabric пачку проверок для себя.

Рад за Руби. Но если ТС выбрал Питон, зачем ему Руби?

Но если ТС выбрал Питон, зачем ему Руби?

мой первый вопрос можно прочесть как:

Ну и вообще нужно ли знание Питона админу или девопсу?

где его применять кроме самописных скриптов, которые выкинут и перепишут по новой при первой возможности?

Всем спасибо. Насчет нужности/ненужности python - не знаю, в вакансиях часто пишут про желательное наличие python скилов. Решил попробовать вкатиться. Хотя лично мне баша пока еще хватает за глаза.

Ну как показала практика, питон сильно расширяет возможности для администрирования. Можно уже писать скриптовые комплексы, без геморроя работать с файлами и текстом

ООП на начальном этапе не нужен, просто потому, что для простых обработчиков процедурного стиля более чем достаточно

# pacman --sync --search ruby- | wc -l
164

# pacman --sync --search python- | wc -l
1462

И, внезапно, зачем админу питон, если есть хацкель

# pacman --sync --search haskell- | wc -l
1062

И, внезапно, зачем админу питон, если есть хацкель

слышу речь не мальчика, но мужа.
но, всё же, писать самопальные костыли, вместо yml файлов — это экстремальное администрирование.

А что ты скажешь на то, что у ansimble звезд больше, чем у chef и puppet вместе взятых

писать самопальные костыли, вместо yml файлов — это экстремально

http://docs.ansible.com/ansible/latest/YAMLSyntax.html

Ну как показала практика, питон сильно расширяет возможности для администрирования. Можно уже писать скриптовые комплексы, без геморроя работать с файлами и текстом

Как показывает практика, знание баша у очень многих админов, мягко говоря, не ахти.

Оно вообще мало у кого «ахти». Очень уж специфичная штука, со всякими врожденными недостатками и кучей подводных камней. Пытаться на нем писать что-то длиннее простенького коротенького скрипта - тот ещё изврат, лучше уж взять любой другой скриптовый язык.

Нужно, и даже очень. А потом и руби (груви) придется вкурить скорее всего, и основы жабки.

Очень уж специфичная штука, со всякими врожденными недостатками и кучей подводных камней.

Если сложность считать недостатком, то да. Но я писал о тех, кто куцую официальную документацию не сподобились до конца прочесть и осмыслить.

Вместо официальной документации надо вкуривать всякие abs, http://mywiki.wooledge.org/BashPitfalls и т.п. И зачастую простые вещи делаются неочевидным способом, чтобы не наступить на какие-нить грабли. И всё равно никуда не деться от освоения в каком-то объеме sed, awk или даже perl.

По теме - хоть какое-то представление об ООП надо иметь т.к. в питоне всё - объект.

в питоне всё - объект

Ты путаешь с Руби. В Питоне примитивные типы не являются полноценными объектами: попробуй расширить тип int.

Вместо официальной документации надо вкуривать всякие abs
Вместо

Отсюда и проблемы. Да и вкуривают не Вуледжа.

И всё равно никуда не деться от освоения в каком-то объеме sed, awk или даже perl.

В подавляющем большинстве случаев, вполне можно обойтись.

Ну, попробовал.

class MyInt(int):
    def __div__(self, n):
        return MyInt(self*n)
   ....:     

In [12]: x = MyInt(2)

In [13]: x/2
Out[13]: 4

Изменять поведение самого встроенного объекта ты не можешь, by design, но наследоваться можешь.

Но мой пост был не про это, а про то что любые строки, списки, сокеты, классы стандартной библиотеки и прочее - это объекты, с методами и т.п. Надо представлять что это такое, хотя бы.

Ну, попробовал.
class MyInt(int):

Are you kidding me?
Любой pure Python объект в питоне можно расширить, встроенные типы — нельзя. Расширить, а не отнаследовать от них.

Но мой пост был не про это

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

встроенные типы — нельзя

И не нужно. Если тебе нужно другое поведение, делай новый тип, наследуйся. Манкипатчинг классов - тоже, обычно, зло. Но это моё ИМХО и не только моё и я не вижу смысла холиворить на эту тему.

От того, чтобы не можешь менять их поведение они не перестают быть объектами.

А, я понял что ты имеешь ввиду.

Любой pure Python объект в питоне можно расширить

Не любой, если у него задан __slots__ - нельзя. Зато, если он задан - это экономит оперативку.

А, я понял что ты имеешь ввиду.

Нет, не понял. Если у тебя есть одни объекты и другие, которые как бы объекты, но не совсем, говорить, что «всё есть объект», значит лукавить и грешить против истины. Это не пуризм с моей стороны, это объективность.

Потому что оно не нужно https://habrahabr.ru/company/mailru/blog/311762/

Что не нужно? Знать язык на котором пишешь? Понимать как передаются параметры или то, что выхлоп внешних утилит и имена файлов могут содержать символы подстановки и прочую тарабарщину, а потом свой тупняк гордо обозвать «подводными камнями».

Знать язык на котором пишешь?

При всей куцости баш, подводных камней у него подозрительно дофига. Складывается впечатление, что этап проектирования к нему попросту не применялся.

Понимать как передаются параметры

И как возвращаются. Никак.

Универсальный солдат - это из голливудских фантазий

А не надо микроскопом гвозди заколачивать. Язык оболочки - это язык оболочки, не больше и не меньше. Со своими обязанностями он справляется уже десятилетия, попутно развиваясь. Ассоциативные массивы вам завезли, а вы всё ворчите.

При всей куцости баш, подводных камней у него подозрительно дофига.

Задолбали вы со своими камнями. Сначала RTFM, а потом с камнями приходите, если найдёте.

А что может быть сложного в ООП?

а потом с камнями приходите, если найдёте.

Ссылку на wiki уже приводили. Дальше по ссылкам походить и еще найдутся. Грабли и плохой дизайн выливаются в искусственно завышенный порог вхождения. Изучая больше, профита меньше.

Ну если справляется, хорошо, но без меня

Мне граблей хватило

для решения админских задач

тут вопрос не в этом, а в том, насколько эти задачи требуют создания сложного ПО. если требуемый код сложен и объёмен, то лучше взять Golang.. да и прога голанговская - скорее будет работать при отсуствии в системе питона.

А, да.. если нужно именно разобраться в ООП, то лучше брать C++ или Java.. в python - это огрызок, а не ООП.

если нужно именно разобраться в ООП, то

Лучше брать Eiffel, а какахи вроде C++ или Java оставить тем, кто на них вынужден денюжку зарабатывать, обливаясь ежедневно кровавыми слезами.

попробуй расширить тип int.

так?

class A(int):
    def aaaa(self):
        print("lol")

a = A()
a.aaaa()

lol