Pull to refresh

Comments 54

Яндекс любит Python (раньше Гугл тоже его любил, но теперь у него есть Go)

В Яндексе тоже есть Go, и его там тоже любят. Просто в инфраструктурных командах и в критичных по производительности местах удобнее Go, а для сложной бизнес-логики и перекладывания джсонов лучше подходит питон.

JS JSONы хуже питона перекладывает?

Я JS не очень глубоко знаю, и его эффективность в перекладывании джсонов не берусь оценивать. Но по совокупности плюсов и минусов в целом по индустрии для бэкенда питон считается более подхлдящим, чем JS.

Что имеется в виду под дополнительной настройкой окружения для работы с promise/async-await?

В статье произошёл рассинхрон. Делаем 50 приседаний на сложение/вычитание, а в выводе объявляем что node лучше django, а асинхронность в питоне плохая. Надо либо вывод по математическим приседаниям делать, либо исследовать фреймворки и асинхронность.

Существенное преимущество JavaScript заключается в том, что он не нуждается в интерпретаторе, т.е. код на JS выполняется браузером напрямую. Это очень сильно облегчает разработку веб-приложений.

Что значит выполняется напрямую? В браузере уже нет встроенного интерпритатора? Или вы хотели сказать что в браузере нельзя выполнять код написанный на python напрямую? А что такое разработка веб-приложений? Это только клиентская часть, или и северная тоже? Запустить код на сервере что на python, что на javascript одинаково легко.

>>> В браузере уже нет встроенного интерпритатора?

Есть. Для JS. Для Питона нет. Я думаю речь об этом.

Код на JS может отработать на странице, которую вы написали в блокноте, сохранили локально и открыли в любимом браузере.

<script type="application/javascript">
  alert('Hello, World!');
</script>


Я не специалист (ни в js, ни в py), но с питоном такая тема, как мне кажется, невозможна… Или я чего-то не знаю?
Ну это уже читерство! )))

Хотя прикольно.

любимом браузере

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

Ага, много разных версий питона, причем далеко не везде, из-за чего при распространении ПО на питоне всегда надо встраивать интерпретатор в бандл с питоном

разных версий питона

По моему опыту, для большей части кода важно 2-й это питон или 3-й. Внутри мажорной версии проблем с обратной совместимостью я не встречал. Использовать только определённую версию может потребоваться только при подключении внешних библиотек написанных например на C. Ну так с чистым javascript тоже самое, не говоря уже про разные движки для него. С движками сейчас только стало полегче после появления явного лидера.

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


Например
        except (AttributeError, ValueError):


Поддержку этой конструкции выпилили, если не ошибаюсь, в python 3.6, и некоторые скрипты при обновлении внезапно перестали работать. Особенно забавно, когда это давно не обновлявшаяся библиотека, которую притащил pip.
Возможно, это что-то другое было. Deprecated в 3.6 и окончательно выпилено в 3.8. При переезде с 18.04 на 20.04 оно себя именно так проявило — как syntax error. Нужно будет перепроверить ;) Завтра поищу тот кусок кода.

На самом деле в тег script можно интегрировать любой скриптовый язык. Только вот работать будет не везде. Помнится 15 лет назад баловался запуская код в IE в теле script, написанный на RSL. Это язык, используемый в банковской системе RS-Bank. Для этого нужно было всего лишь установить какую-то dll в Винде от разработчика RS-Bank. К сожалению материалов по этому в интернете не нашёл.

Кстати. Тогда и VBScript в IE работал и именно его я начинал использовать вместо JS.

Нативно есть только JavaScript или WASM.

Для демонстрации Python можно взять Brython: https://brython.info/

Для Питона хочется сделать препроцессор, чтобы можно было писать в C-like нотации, которая одновременно и лаконичная, и четко визуально определяемая - но тогда Питон превратится в JavaScript ;)

С непривички глаз царапается двоеточиями там, где должно быть начало блока и этой ужасной концепцией отступов, как окончаний. Говорят, что очень сложно одновременно грамотно писать на русском и белорусском - так как правила правописания там полярны. Видимо после плотного питонизма автоматизм ставить закрывающие фигурные скобки тоже будет утрачен :)

этой ужасной концепцией отступов, как окончаний.

А чем она ужасна? Тем, что отучает писать код без форматирования и однострочники? Это же прекрасно.

Тем, что не оставляет писателю выбора. Поэты пишут лесенкой, но конец предложения - всегда точка. Также и в языках программирования. Иногда нагляднее записать в одну строку, иногда разнести отступами. Если есть явный конец блока - у меня есть эта свобода. Если его нет - то этой свободы нет.

О, нашёлся великий поэт. Codestyle? Не, не слышал. Production требует линтов, форматтеров и тайп чекеров имеено из-за обилия великих поэтов.

Ассоциирование автора аллегории с субъектом, в ней описанным - довольно странная затея, более характерная для описанной Жванецким категории "Зачем спорить с хромым об искусстве, когда можно сразу ему сказать, что он хромой"

По поводу же синтаксиса - код смотрят не только в IDE в окружении подпорок-линтеров. Могут посмотреть и в нотепаде, и даже (архаика!) на бумаге. И без подпорок ориентироваться на пробелы очень сложно. Поэтому отсутствие видимого глазом закрывающего блок символа - в общем случае рискованное предприятие.

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

Ассоциирование автора аллегории с субъектом, в ней описанным - довольно странная затея, более характерная для описанной Жванецким категории "Зачем спорить с хромым об искусстве, когда можно сразу ему сказать, что он хромой"

Занимайтесь "искусством" сколько влезет. Главное, в коммерческую разработку не лезте. Там и без вашего "искусства" проблем выше крыши.

Хотя следует признать, что 95% проблем носят рахитектурный характер. Банальное соблюдение хотя бы SRP -- это заоблачное ожидание от людей "искусства".

По поводу же синтаксиса - код смотрят не только в IDE в окружении подпорок-линтеров. Могут посмотреть и в нотепаде, и даже (архаика!) на бумаге. И без подпорок ориентироваться на пробелы очень сложно. Поэтому отсутствие видимого глазом закрывающего блок символа - в общем случае рискованное предприятие.

Не распечатывайте на бумаге yaml, пожалуйста.

Что до обмазывания линтерами и форматтерами -- к сожалению, это необходимость. Бороться с линтером и форматтером, всобачивая изредка в код # noqa и # fmt: on/off или // prettier-ignore сильно проще, чем спорить с опытными и адекватными людьми, которым стрельнуло утворить дичь.

Что до "нотпада" -- иногда так случается, что хитрый баг воспроизводится только на проде. Я понимаю, что вы привыкли к "нотпадам" на серверах -- уж простите, но мы выбираем между nano и vim. Вот отсюда и далее у меня возникает стойкое ощущение, что лыжи не едут вовсе не у меня.

Да, на бумаге код ни разу не печатал, каюсь. Кстати, а вы?

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

Правильно ли я понимаю, что минифицированный JS со скобочками и ; вам читать легче, чем код на python? Что-то мне подсказывает, что вы не честны даже с самим собой. Любой психически здоровый разработчик выделит вложенный блок отступом. Вложенный блок (подвыражение) может выделяться скобками как обычными -- это справедливо для большинства языков. Вложенный блок может выделяться фигурными скобками, а также выражениями begin/end, if/fi + for/done + while/loop и прочими.

Теперь вопрос: если вложенный блок уже выделен отступом -- нужен ещё один синтаксис выделения блока?

Читаешь статью от школьника который написал довольно хороший клон хабра, а потом видишь это и от списка задач глаза широко открываются. А Вы в каком классе учитесь?
Ну и в целом полнейшая отсебятина притянутая за уши...

Питон на сервере. Для вебразработки.

Да, там он работает. Как модуль Апач.

А если мы хотим без Апач, что бы быстро и много пользователей одновременно (через связку NginX->PHP FPM), то Питон тут уже не гуд.

Посдкажите, плиз. Я правильно понимаю?

Нет. Для питона есть свои wsgi и asgi веб серверы. например uwsgi, gunicorn, nginx-unit.

Маленькие замечания по питону:
1)lambda — синтаксис для анонимных функций и используются однократно, например в сортировках. Если нужно переиспользовать, то стоит обьявлять синтаксис с def.
2)Внутри f-строк не стоит производить вычисления и/или вызовы функций, желательно передавать уже готовые значения.
3)В питоне есть красивый синтаксический сахар в виде генераторов выражений, который позволяет не использовать нагромождение map|filter|lambda

Внутри f-строк не стоит производить вычисления и/или вызовы функций, желательно передавать уже готовые значения.

Можете пояснить почему: какой-то этический момент python, или это связано с возможным ухудшением производительности?

В целом, это достаточно холиварный момент. Общего соглашения в виде pep'a нет, кто-то использует, кто-то нет.
Но это сильно портит читаемость кода и потихоньку приходят к решению, что это — антипаттерн.

Два чаю вам за этот комментарий. Внесу некоторые пояснения

1) Дело в том, что гениальный JS фундаментально разделяет обычные функции и стрелочные функции (то, что в других языках называют лямбдами). И ввиду этих фундаментальных различий это на самом деле 2 разных инструмента

2) Удваиваю и отвечу @Timergaleev -- на таких f-строках слишком легко допустить исполнения достаточно тяжёлого кода. Поясню -- основная проблема в исполнении потенциально ненужного кода (привет, логгирование), который при этом может оказаться ещё и тяжёлым

3) map/filter лучше всего комбинировать с готовыми функциями. То есть если есть кирпичики -- map/filter. Нет кирпичиков -- синтаксис генераторов. Сложная логика в генераторе -- таки выносим её в кирпичики и или возвращаемся к map/filter, или всё делаем на yield (который в JS тоже кстати есть)

JS фундаментально разделяет обычные функции и стрелочные функции (то, что в других языках называют лямбдами)

"фундаментальное" различие там только во внешних this/arguments для стрелочных функций. На представленных примерах это никак не проявится. Так что менять одно на другое можно без проблем, просто стрелки короче.

По первому же примеру видто что вы не питонист

print('Hello world!')

Иначе вы бы знали, что у питона батарейки в комплекте:

import __hello__
>По первому же примеру видто что вы не питонист
Это написано у автора прямо в первом же предложении.
для сравнения синтаксиса двух языков использование import __hello__ — это конечно прям то, что надо, ага… ;)

В свою очередь, в Node.js в последнее время царит некоторая неразбериха за счет одновременного существования двух разных подходов к разработке: одного, основанного на колбеках, который считается устаревшим, и другого, основанного на промисах и async/await, который требует дополнительных усилий по настройке окружения и не в полной мере заменяет первый подход.

Это как так? Под настройкой окружения, как я понимаю, имелся в виду какой-нибудь babel.

async/await из коробки в Node.js уже c 7-й версии есть, Promise - и того раньше.

Так что более 4-х лет никакое окружение настравать не надо.

Мне кажется сравнивать языки путем написания одного метода/функции - не корректно.

Это сродни тому, что сказать, что в Numbers и Excel одинаково работает SUM, поэтому они очень похожие и можно легко прыгать с одного на другой. Сродни тому, что сказать, в Google Sheets и в SAP можно создать таблицу с заголовками, поэтому можно легко не платить за SAP и пересесть на Google Sheets

Если сравнивать языки, то надо не забыть про
- наследование и прототипы
- встроенные в язык библиотеки/модули
- обработку ошибок
- весь синтаксический сахар
- обновление языка, совместимость, процент тех, кто сидит на последней версии
- и многое-многое другое

Конкретно про Web-разработку - еще больше всего.

А то так можно порешать задачки на Go и TypeScript и обнаружить, что они очень похожи)
Но при этом они настолько разные, что их даже и сравнивать-то глупо. Как карьерный самосвал и железнодорожный локомотив

невероятно увлекательно, не правда ли?

Нет. Интересной здесь была только задачка 4 про площадь, и только для Герона Александрийского..

А мне понравилось. Я вот не знал решения большинства задач, в том числе вычисления площади треугольника (с математикой сталкиваться не приходится).
Решил 50 задач и ответил на вопрос — Python или JavaScript?

Не смотрели для сравнения существующих решений этих и других задач на http://rosettacode.org?

P.S. Интересно, что на rosettacode.org JavaScript 744 решённых задач ,
а на Python — 1,269 и в 18-ти категориях
Какой-то детский сад от студента, только начинающего осваивать программирование.

Предложенная функция определения простого числа имеет сложность O(n), хотя достаточно O(√n): если n — составное число, то один из множителей заведомо не превышает √n.

Функция определения високосного года переусложнена. Автор не знает способы упрощения логических выражений?
return ['not leap', 'leap'][year % 4 == 0 and (year % 100 or year % 400 == 0)]
В JS только and и not поменять на && и ||.

Определение чётности в Python:
return ['even', 'odd'][n % 2]
В JS остаток отрицательного делимого — отрицательное число, потому проще использовать битовые операции:
return ['even', 'odd'][n & 1];

Предложенные автором функции вычисления НОД и НОК — откровенная безграмотность:
def gcd(a, b):
    while b: a, b = b, a % b
    return a

def lcm(a, b): return a * b // gcd(a, b)

И т.д. по списку…
Что я только что проскроллил? Смысл всей работы это сравнение синтаксиса стандартных библиотек двух никак не пересекающихся языков. Надеюсь автор хоть печатать быстрее научился, иначе совсем всё зря.

const myList = []

// ! - [] -> 0 -> false + ! - false -> true

if (!!myList) { console.log('Empty') }

Добро пожаловать в мир пустых массивов, всех, абсолютно!

Да, Хабр стал более доступен для "школьников"

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

В 12 задаче опечатка в первом условии питона

  • индикатором отсутствия значения в Python является None, а в JS у нас целых 3 таких индикатора — undefinednull и NaN

В JS индикатором отсутствия значения является только null.
undefinedзначит, что переменная существует, но значения не имеет.
NaN вообще значит, что в переменной не число. Но никак не "пусто".

undefinedзначит, что переменная существует, но значения не имеет.

А как же обращение к свойству объекта которого у объекта нет?

;[x, y] = [y, x]

Объясните кто-нибудь пожалуйста.

Точка с запятой перед '[' нужна только потому, что автор принципиально не ставит точек с запятой после операторов. Такое пренебрежение ';' допустимо в JS, но является дополнительным источником ошибок. Потому — на всякий случай — автор впихнул ';' перед присваиванием: очередное героическое преодоление собственноручно созданных трудностей.

Что касается [x, y] слева от присваивания, то это называется «деструктуризация массива» и описывается в любом современном учебнике. Например: learn.javascript.ru/destructuring-assignment

Если своими словами, то элементы массива справа от '=' присваиваются переменным, перечисленным в [] слева от '='. Т.е., упрощая, при выполнении [x, y] = [y, x]; сначала создаётся массив tmp = [y, x], а потом производится 2 присваивания: x = tmp[0] и y = tmp[1].

Про деструктуризацию был в курсе.

А вот ; поставило в ступор.

Так и не понял зачем оно там. И так все работает. Автор ещё на этом заостряет внимание будто это важно...

У автора в статье много странного кода. Единственное вменяемое объяснение этой абсолютно ненужной ';' я вижу в том, что автор опасается, что данное выражение может быть склеено интерпретатором JS с выражением в предыдущей строке кода (в конце которого автор принципиально ';' не поставил).

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

Это действительно важно, пример автора работает и без нее, но если написать

```
let x = 1
let y = 2
[x, y] = [y, x]
```
Подобный код не скомпилируется

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

```from random import randint

# такая функция называется лямбдой

get_random_int = lambda min, max: randint(min, max)

print(f'Случайное целое число в диапазоне от 0 до 100: {get_random_int(0, 100)}')

```

Что с вами не так? Зачем было в лямбду функцию засовывать, если без лямбды можно было напрямую вызвать? Тем более, зачем вы присваиваете имя лямбде? Смысл лямбды в том, что у неё нет имени ...

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

Мало использовать синтаксис языка, нужно думать на этом языке. Большинство программ написано не питоническим путем совсем. Прям явно бросается в глаза, что автор сначала представил себе алгоритм на JS и потом перевел на питон. Я совсем не спец в питоне но небольшой опыт имеется. И я бы написал программу по рисованию пирамиды намного проще, в 2 строчки.

 def draw_pyramid(delimeter, rows):

for i in range(rows):

print(' ' * (rows - i - 1) + delimeter * i * 2 + delimeter)

def draw_up_side_down_pyramid(delimeter, rows):

for i in range(rows, 0, -1):

print(' ' * (rows - i) + delimeter * (i - 1) * 2 + delimeter)

if __name__ == '__main__':

draw_pyramid('@', 10)

draw_up_side_down_pyramid('#', 10)

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

Sign up to leave a comment.