Обзор языка (2 серии части)
Нет сомнений, что Python популярен, но для меня он слишком похож на змею, с которой он разделяет имя; Круто, чтобы смотреть, но слишком ненадежно, чтобы справиться.
Конечно, есть исключения из каждого правила, и некоторые люди великолепны в написании на Python. Возьмите, к примеру, команду, которая создала Ansible. Его код хорошо организован и читается. Ясно, что у них есть набор определенных стандартов, которые они следуют. То, как они используют Python в качестве языка, тоже фантастическое. Они пользуются тем фактом, что Python развернут в большинстве систем Linux, чтобы сделать невозможным без агента. Если вы не уверены в том, что это значит, вы должны проверить мой Теоретически: ansible Сообщите, но просто знайте, что это довольно круто!
Хорошо, достаточно дополнять Ansible. Давайте доберемся до очков.
Многие люди изучают Python как свой родной язык, и это понятно. С одной стороны, у него нет всех символов, которые есть у других языков. Посмотрите на следующие два фрагмента из C ++ и Python, соответственно.
// age.cpp
int age = 18;
if (age >= 18) {
std::cout << "Welcome!" << std::endl;
} else {
std::cout << "Sorry, you must be at least 18 to enter." << std::endl;
}
# age.py
age = 18
if age >= 18:
print("Welcome!")
else:
print("Sorry, you must be at least 18 to enter.")
Это очевидно, но фрагмент C ++ более многословна в нескольких способах. Для новых программистов это слишком быстро.
Еще одна вещь, с которой Python легче работать, – это абстракция указателей. По моему опыту, указатели – самая сложная точка обучения для новых программистов. В Python все проходит, что означает, что вы можете обойти указатели. Не нужно беспокоиться о том, чтобы делать ссылки и дрефермер.
Python’s Стандартная библиотека Очевидно, съел свои овощи в детстве, и это здорово. Это означает, что из коробки вы можете многое сделать с этим. Все, от криптографии, до рисования в терминале, приложений для графического интерфейса, до взаимодействия базы данных находится под рукой, и это то, что я люблю видеть на языке.
Если вы много используете Python, серьезно посмотрите на то, что доступно. Возможно, вам не понадобится столько сторонних пакетов, сколько вы думаете.
Поскольку Python так популярен, его сообщество огромно. Вы можете найти библиотеку, чтобы сделать практически все. Вот статистика для Pypi На момент написания этого:
Это очень хорошо! Они не так высоки, как что -то вроде Maven или NPM, но это может быть хорошо. Это означает, что при работе с зависимостями гораздо меньше беспорядка, но есть и достаточно вариантов.
“Но машинное обучение делается с Python все время! Это должен быть быстрым!” Я слышал, как ты говоришь. Это на самом деле ложь. Созданы обертки Python, которые на заднем плане скомпилированных C -Call, и большая часть работы выполняется в C. python, действительно, очень медленная. Недавно я нашел библиотеку машинного обучения, написанную на Pure Python, которая заканчивает 3-4 дня! Если бы это было написано в чем -то вроде C, это заняло бы менее часа. Если вам нужны метрики, проверьте любой из приведенных ниже ресурсов. Доверяете ли вы им или нет, зависит от вас, но код доступен, чтобы осмотреть для себя.
- https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html
- https://github.com/kostya/benchmarks
Причина, по которой это указано только как «мех», заключается в том, что в большинстве современных приложений скорость не имеет значения. Большая часть программного обеспечения имеет тенденцию быть «достаточно хорошим», и если вам нужно что -то сделать быстро, вы всегда можете написать код C, чтобы взаимодействовать с ним. Но вы, конечно, не собираетесь писать быстрый системный монитор в Pure Python.
В Python нет контроля доступа. Есть ли функция утилиты, которая будет использоваться только в вашем пакете? Это не имеет значения, кто -нибудь может получить к нему доступ. Если вы не думаете, что это проблема, вы, вероятно, не рассматриваете документацию, которая будет сгенерирована для вашего кода. Для других разработчиков, которые хотят работать с тем, что вы делаете, не будет сразу ясно, что вы намереваетесь использовать, в отличие от того, что вы написали только для внутреннего использования. Вы можете обойти это, используя подчеркивание ( _ ) в качестве префикса для частной функции, подобной этим:
def _my_helper():
# do something
pass
def my_worker():
# do something
_my_helper()
Это всего лишь «мех», потому что, если вы можете убедиться, что все следуют этому простому правилу, вы можете обойти многие проблемы, по которым все, что является публичным.
Динамический набор текста – еще один пункт продажи для новых разработчиков. Почему бы не было? Нет необходимости беспокоиться о дополнительных накладных расходах на типы переменных. Когда вы назначаете номер переменной, переменная содержит число. Это так просто. Вот еще один пример C ++ против Python:
// add.cpp
int addOne(int num) {
return num + 1;
}
int main() {
int n = 0;
n = addone(n);
std::cout << n << std::endl; // => 1
return 0;
}
# add.py
def addOne(num):
return num + 1
def main():
n = 0
n = addOne(n)
print(n) # => 1
Если вы фанат этого, я понял. И, работая над своим собственным проектом, это только для вас, все в порядке. Но когда вы хотите работать с другими людьми, это очень расстраивает Анкет Что мешает мне сделать это?
# add.py
def addOne(num):
return num + 1
def main():
n = 0
n = addOne("hello") # adding a string
print(n) # => ERROR
Абсолютно ничего Анкет Невозможно обойти тот факт, что из -за динамического набора текста любой может передать что -либо к этой функции. Если бы я попробовал это с C ++, я бы знал, что допустил ошибку еще до того, как программа даже запустилась. Есть тонны тонких ошибок, которые возникают при случайном использовании неправильных типов в неправильных местах; Проблемы, которые будут решены со статическим набором.
Так как же это обойти это? Документация. Ожидается, что вы напишите достаточно хорошей документации, чтобы пользователи знали, что им следует ожидать, чтобы работать с вашим кодом. Давайте переписать функцию, чтобы включить некоторые.
# add.py
def addOne(num):
"""
Add 1 to 'num'.
@type int
@param The number to add 1 to
@return The result of adding 1 to 'num'
"""
return num + 1
Итак, мы задокументировали это, и ясно, чего сейчас следует ожидать, верно? Хорошо обязательно. В то же время, однако, вам пришлось сделать гораздо больше работы, чем просто добавление ключевого слова инт Как вы могли бы сделать в C ++, который позаботится о том, для чего вам нужна документация в первую очередь. Другая проблема в том, что Вы просто не можете доверять большинству разработчиков Анкет Большинство разработчиков просто не будут беспокоиться о том, чтобы писать такую документацию, и Python их не заставит их. Статическое набор, хотя. По крайней мере, даже если разработчик плохо документирует, вы будете знать, какими должны быть параметры, и что вы вернете от
Хорошо хорошо. Итак, вы готовы написать документацию для своего кода, и вы хотите сделать это правильно. Хороший! Но также удачи. Инструменты документации Python – это только худший Я видел на любом языке, с которым работал. Инструмент документации Python по умолчанию – Pydoc, и вот пример того, как выглядит его вывод, сгенерированный из официального Sys Пакет стандартной библиотеки.
Я не собираюсь обсуждать, насколько это уродливо, потому что это не так, но это просто голые кости. Есть ссылки на функции и все такое, но это все. Давайте сравним это с Ruby’s площадка жемчужина
Для меня разница в том, что день и день. У Ruby также есть динамическая набор, но инструменты документации настолько хороши, при этом поддержка, такая как официальная нотация для печати и боковое навигационное дерево, что это значительно облегчает работу. Это большое дело при работе с другими людьми.
Чтобы быть ясным, вполне может быть лучшие инструменты документации для Python; На самом деле, я уверен, что есть. Но инструменты Python по умолчанию – это то, что большинство людей собираются использовать, и если инструменты по умолчанию плохие, документация, вероятно, также будет.
Редактировать [15.01.20]: Недавно я играл с Doxygen, который был намного лучше, чем встроенные инструменты, и могу выполнить работу в достойной степени. Тем не менее, из -за динамического набора текста, это гораздо больше работы, чем было бы со статическим набором.
Я не фанат того, как Python обрабатывает зависимости. По какой -то причине были созданы «колесные файлы», что является форматом для зависимостей Python. Проблема с ними заключается в том, что они иногда связаны с конкретными архитектурами или версиями Python. Например, если я загружаю колесный файл для Python 3.7, и у вас есть Python 3.5, О, хорошо, ты не можешь его использовать! Я получаю совместимость с версией, но это выходит за рамки этого. У вас должны быть точные спецификации для установки определенных колесных файлов. Для людей, работающих в автономной среде, это очень расстраивает. Они не могут просто сохранить папку от зависимостей, которые им нужны для своей автономной машины, поскольку они могут быть легко бесполезными, если они обновляют мою версию Python.
Другой вариант – загрузить архивный исходный код, и это имеет тенденцию работать довольно хорошо. Это не требует конкретных версий Python или архитектуры. Это работает достаточно хорошо, чтобы вы могли задаться вопросом, почему колесные файлы существуют. С моей точки зрения, кажется, что кто -то сказал: «Знаете, архивные исходные файлы работают отлично, но почему бы нам не затруднять для разработчиков работать с зависимостями? ” Может быть, я что -то упускаю, но ни у одного другого языка, с которым я сталкивался эта проблема.
Но на что я жалуюсь, если я могу просто использовать файлы TAR, тогда? Ну, оказывается, что некоторые разработчики пакетов просто не предлагают их. Конечно, вы всегда можете пойти в репозиции GitHub, где находится источник, но затем вы столкнетесь с проблемами с различными структурами каталогов и отсутствием официальных выпусков, как есть PYPI.
Python не одинок в этой проблеме, так как это в основном просто проблема с интерпретируемыми языками в целом. Проблема в том, что когда вы хотите отправить свой код Python кому -нибудь еще, это делает несколько шагов.
Например, если вы использовали какие-либо сторонние зависимости, другому нужно будет загружать их сами. Вы не собираетесь делать что-то в Python и попросить своего друга-компьютерного друга использовать его, как вы сможете сделать на скомпилированном языке.
Портативность является особой проблемой для людей в автономных средах, где каждое изменение зависимости и развертывание является огромной сделкой. Было бы гораздо удобнее, чтобы зависимости связаны друг с другом, что возможно с помощью процесса, называемого «заморозом», но мне не повезло с замораживающим кодом Python в большем количестве случаев, тогда я хочу поговорить, где это Либо требуется подключение к Интернету, где у меня не было ни одного, либо полученное исполняемое файл просто не работает.
Было время, когда я любил Python. Когда было это время? Это было, когда я только знал C ++. Конечно Python будет отлично выглядеть, если это единственный язык, который вы знаете. Это было легко, и это сделало для вас работу. Но в реальной, практической, повседневной среде это просто не летит для меня. У языков слишком много лучших вариантов, чтобы начать с того, что решает проблемы, которые есть у Python.
Я надеюсь, что это очевидно, что «хорошие», «плохие» и «мех» ярлыки являются моим мнением; Я не пытаюсь выпустить их как факт. Если вы ничего не согласны, дайте мне знать! Мне понравится обсуждать это. И если вы заметили, что я сказал что -то, что объективно неправильно, опубликуйте комментарий! Я открыт, чтобы изменить свой разум.
Спасибо за чтение!
Обзор языка (2 серии части)
Оригинал: “https://dev.to/rburmorrison/language-review-yikes-a-python-4h9l”