>> CPAN,
> И чем он лучше pip?Найдите мне в pip нормальный модуль для работы с SNMP, чтобы работал быстро, можно было прочитать одну доку за 15 минут и сразу начать использовать. Есть целых три и все - говно. Самое вменяемое - биндинги к Net-SNMP, но и там API какое-то странное.
Нельзя прямо на сайте ознакомиться с документацией и примерами, чтобы из вороха найденного в поиске быстро отобрать что-то годное, в отличие от CPAN.
>> быстрые, полноценные и более удобные в использовании регулярки,
> Чем какие?
Чем модуль re.
>> меньше проблем с кодировками, похожесть на shell, в среднем более толковая документация, автовивификация,
> Вот теперь нужно развить тему о том, что не так в кодировках
> в python, и что там не так документацией, которая автоматическая в
> python с рождения в отличии от perl.
Python не подхватывает автоматом кодировку из окружения. Есть два типа строк, тип которых нужно указывать явным образом, используя или не используя префикс u. Нельзя глобально задать кодировку ввода-вывода для всех файлов и стандартного ввода-вывода. В Perl можно просто включить прагму utf8 и указать кодировку файлов с помощью прагмы open. В Python же ещё нужно и при использовании регулярок явным образом указывать флаг, чтобы сказать, что регулярка должна работать с юникодом.
Документацию в Perl просто гораздо чаще пишут не на отъебись, а так, чтобы её можно было читать, как литературу, с примерами и подробными объяснениями.
>> возможность проверять наличие переменных и полей классов ещё на этапе компиляции
>> (use strict, use fields), что позволяет писать быстро и без необходимого
>> 100% покрытия кода тестами.
> На этапе компиляции? facepalm.jpg
Да, представьте себе. Если при компиляции обнаружится, что где-то в программе я присваиваю значение не объявленной переменной или полю класса, программа просто не скомпилируется и не запустится.
В отличие от более динамического и всего из себя такого ретроспективного Python, который сначала отработает несколько часов, а потом "неожиданно" обнаружит, что где-то используется не объявленная переменная и выкинет исключение.
>>Менее богатый набор типов позволяет меньше думать
>> о приведении типов (есть, например, отдельные операции конкатенации и сложения, отдельные
>> операции сравнения строк и чисел).
> Чем меньше возможностей тем хуже?
Бывает выбор, а бывает псевдовыбор. В Python много псевдовыбора, не смотря на его декларируемый DRY. Вам обычную строку, строку юникод или строку из байтов? Вам метод строковой функции или функцию для работы со строками? Вам целое число, длинное целое, с плавающей запятой или комплексное? (Ну ладно, комплексные ещё можно выделить в отдельный тип). Вам import module, from module import func или from module import *? Вам pysnmp, yasnmp или netsnmp? Вам range или xrange? А давайте переименуем xrange в range, чтобы вам думать не пришлось? Ну только тогда вам нужно будет исправить все ваши программы.
Эта мелочность python просто выбешивает, потому что в нём постоянно передвигают мебель с места на место (понемножку меняют поведение малозначимых вещей, так что вроде и ничего не изменилось, а исправлять свои программы приходится) и без virtualenv бывает сложно сосредоточиться на собственно самом проекте. В код на Perl можно просто не заглядывать годами, потому что в нём всё давно устоялось и продолжает работать так, как и работает много лет.
