Комментарии 24
Отлично, спасибо большое за интересный обзор!!
Python Script
А есть текстом больше деталей про концепт этого? Насколько мне известно уже есть как минимум скомпиленный CPython (тот же jupyter) для браузера и реимплементация Python3 на Rust, которая тоже запускается в браузере.
То бишь официальная реинкарнация Brython
Это вообще ни разу не Брайтон, каковой являлся тормознющим интерпретатором Питона на Яваскрипт.
PyScript - это полноценный Питон на wasm, который по скорости работает в десятки раз быстрее Брайтона, как обычный Питон примерно. По крайней мере, исходя из моего опыта.
На Брайтоне невозможно было сделать хоть что-либо серьёзное, как чуть циклов добавишь и браузер подвисает на несколько секунд
Ребята, ничего лично не имею против Питона. Абсолютно.
Но почему мне для сборки прошивки в embedded устройстве, написанной на C и ARM Assembler, нужен интерпретатор Питона? Я открываю IDE для CLang и там Питон во все поля и всё подтормаживает. Когда так стало?
Это вопрос к разработчикам этого конкретного проекта, которые решили использовать Python для скриптов или какой-то инструмент на python (например, Conan). И использовали неправильно, раз есть подтормаживания.
Странный вопрос. Это как если бы я написал, что ничего не имею против C, но посетовал, что прошивка на одном из моих устройств глючная.
Потому что скрипты на баше писать и поддерживать больно. Да ещё и у каждой ОС по своему диалекту. А питон точно либо второй либо третий.
MSBuild, Gradle, make в конце концов
MSBuild на маках/линуксах звучит как что-то несуществующее, но это не точно
gradle включает в себя килограмы джавы, что многих не сильно впечатляет. И где это видано, чтобы плюсы джавой собирали. Ну и с пакетными менеджерами в плюсах тоже пока не слишком привыкли работать. Оно где-то рядом с бизонами/мезонами и прочими и имеет кое какую адаптацию, но всё равно на порядок реже чем тот же бизон. На FreeBSD интересно как у них там это живёт.
make/cmake не сильно далеко ушли от bash - те же сотни макроподстановок через тысячи магических переменных с не самыми адекватными способами ассигнований значений, объявленных где-то на 8 папок выше пополам с glob синтаксисом - дебажить их то ещё удовольствие. Да и PEP для таких штук отсутвует, поэтому все проекты собраны кто в лес кто по дрова и никто не знает как сделать чтобы стало хорошо и удобно.
А питон что - хочешь параметров скрипту - держи argparse, хочешь пакеты натягать - вот те pip c колёсами, вот те urllib, чтобы тянуть откуда хочешь, вот те asyncio чтобы все это дело на сабтаски разделить асинхронные и собирать параллельно код с ресурсами, вот те словари, вот те человеческие массивы и списки. Это вам не перловое %#^!%&@#%!%^$ читать, тут все человекопонятно. И скобки какие нравится ставь, а не как в баше - хочу выполняю, хочу экранирую, хочу ещё какой магии ворочу. И циклы с условиями как у людей и даже тесты можно писать не отходя от кассы, если очень хочется.
MSBuild работает на mac/linux, как и dotNET последних версий
А какие у него преимущества перед питоном?
Навскидку:
Статическая типизация
JIT
Single binary
С точки зрения пользователя это всё не очень-то важно.
Статическая типизация и single binary — это удобно, но это лишь немного упрощает установку, а не использование.
JIT скриптам для сборки не очень-то нужен. Большую часть времени занимает сама сборка.
Впрочем, довольно странно сравнивать MSBuild от чистый Python. Первое — это система сборки, а второе — язык программирования. Если выбор между написанием скрипта руками и MSBuild, то для проекта больше пары файлов я б предпочёл MSBuild, который что-то уже умеет делать сам.
Но MSBuild — это очень низкоуровневая штука. Вряд ли кто-то пишет здоровенные XML с описанием проекта руками. Гораздо удобнее сделать инструмент, который будет по более высокоуровневому описанию генерировать проект для MSBuild.
По этой же причине странно сравнивать make и cmake. Первый низкоуровневый, а второй высокоуровневый. CMake просто генерирует код для make, Ninja (мой любимый вариант) или того же MSBuild.
И вот оказалось, что Python очень удобен как DSL для таких высокоуровневых инструментов. XML слишком декларативен. Для сложного проекта его может не хватать, а если добавить динамики это будет выглядет громоздко.
Потому и появились SCons (хотя я его редко вижу) и Conan (очень популярен, но это не совсем система сборки). В Bazel сделали чуть интереснее. Там в качестве DSL используется не Python, а его безопасное подмножество — Starlark.
У такого подхода есть недостатки. В общем случае декларативность удобнее, чем императивность. Но тут много зависит от проекта, так что подход вполне имеет право на существование.
Банальный скриптиг. В том же gdb есть давно. Если есть время можете сразу на ассемблере переписать у разработчиков очевидно его не было.
Особо суровые олды (например Бобук) застали еще и переход с версии 1.5 на 2...
Говорят это было еще веселее. Пользовательская база правда была сильно меньше.
Ага. По-моему, он даже рассказывал об этом в нашем подкасте, когда он был ещё Python Junior Podcast: https://www.youtube.com/watch?v=A8CM0ufpJds
«Что же, мы откинули дополнительные колеса трехколесного велосипеда»
Интересно, а люди, которые используют такие выражения, понимают, что оторвав хотя бы одно колесо у трёхколесного велосипеда -- можно вообще никуда не уехать? Это у двухколёсного велосипеда с двумя дополнительными маленькими колёсами на задней оси можно хоть что-то оторвать для ускорения.
Интересно было бы послушать мнение ведущих подкаста о фреймворке Robyn (под капотом Rust). Он также является и HTTP-сервером (а-ля guvicorn/uvicorn).
Субъективные итоги года в мире Python