Rust всё заменит (нет)
Показать полностью
1
0 просмотренных постов скрыто
Быстрая замена mypy на Rust'е: pyrefly
Еще одно видео про еще один новый тайпчекер для питона на расте!
Много их нынче стало.
В видео:
- Обсуждаем первую версию: pyre-check, обсудили taint analysis
- Сравниваем pyrefly с ty и mypy
- Смотрим на внутреннее устройство
- Применяем на реальном проекте
Ключевые ссылки из выпуска:
– Доклад о pyrefly на PyCon: https://youtu.be/ZTSZ1OCUaeQ?si=s_DPOOzsdeTk5Uqo
– pyrefly vs ty: https://blog.edward-li.com/tech/comparing-pyrefly-vs-ty (сильно советую!)
Вывод: пока очень сырой, много багов, но быстрый. Ключевой вывод: отлично, что есть конкуренция.
Показать полностью
Про Rust
Показать полностью
1
Хороший пре-коммит хук для Python разработчиков
Что такое pre-commit hook? Возможность автоматически проверять код перед коммитом. Может быть разное: прогонять тесты, линтеры, форматтеры...
И я собрал для вас быстрый набор из прекоммит хуков, которые вы можете использовать на любых проектах.
Что в него входит:
- ruff (быстрейший форматтер, делает код красивым)
- pyright (один из быстрейших статических анализаторов кода на Python, посвечивает ошибки в тайп-хинтах. что-то типа проверки типов при компиляции)
- pytest с расширением doctest (прогоняет имеющиеся юнит тесты вместе с тестами в документации, про которые я писал ранее. я еле как нашёл пре коммит хук для этого...)
Как установить?
1. сначала
pip install pre-commit
2. потом создаётё .pre-commit-config.yaml
3. потом вставляете туда
repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: v0.1.5
hooks:
- id: ruff
args: [ --fix, --exit-non-zero-on-fix, --show-fixes ]
- id: ruff-format
- repo: local
hooks:
- id: pytest
args: [ --doctest-modules ]
name: pytest
entry: pytest .
language: system
types: [python]
pass_filenames: false
always_run: true
- repo: https://github.com/RobertCraigie/pyright-python
rev: v1.1.385
hooks:
- id: pyright
4. пишете
pre-commit install
Энджой :)
Ссылка на оригинальный пост:
https://t.me/sh1nke9/375
Показать полностью
Обработка ошибок. Исключения vs Монады
Чуваки из интернета говорят, что исключения - зло, а монады - лучше и вообще будущее. Я потратил 5 часов на то, чтобы разобраться в теме того, как можно обрабатывать ошибки, и в чем разница
Исключения
Что-то ломается, у тебя вылезает ошибка, программа останавливается. При этом, указывается traceback ошибки
Монады
Все значения, которые функции возвращают, у нас оборачиваются в прослойку, она может быть Ok или Wrong (для примера. Ok - ошибки нет. Wrong - ошибка есть. мы сами з коде пишем, какие значения к каким категориям относятся)
И мы вручную проверяем, вернула ли програма Ok или Wrong. Если Ok - продолжаем программа, если Wrong - выводим ограниченную информацию об ошибке и стопаем программу
Я скажу две вещи:
Первая -
НЕТ НИКАКОЙ РАЗНИЦЫ. В ОБОИХ СЛУЧАЯХ ТЫ ПРОСТО ПРОПИСЫВАЕШЬ ИНФОРМАЦИЮ ОБ ОШИБКЕ И СТОПАЕШЬ ПРОГРАММУ (в большинстве случаев)
Вторая -
то, как реализованы монады в Go - это уродство. в Go тебе надо при каждом вызове функции писать
result, err := func()
if err != nil {...}
то есть при каждом вызове функции тебе надо говорить, че делать, если функция вернула ошибку (в большинстве случаев выбрасывать panic). это ничуть не лучше try... except, это не элегантно. в Rust чуть получше сделали с паттерн-матчингом результатов функции
Короче, тема непрактичная и оверхайп. Опять программисты по хуйне в интернете сруться
Но это я знаю точно:
- если ты обрабатываешь ошибки так, то тебя надо уволить:
try:
...
except:
pass
- если ты возвращаешь None в случае неуспеха программы, и не райзишь эксепшн, то так тоже делать нежелательно
Ссылка на оригинальный пост: https://t.me/sh1nke9/354
мем хаха
Показать полностью
1
Языки нового поколения
Большинство нынче популярных языков (C#, Java, C++, JS, Python) не работают с многопоточною настолько хорошо, насколько бы нам того хотелось. Почему так?
Потому что они были придуманы в то время, когда ещё не был придуман процессор с двумя ядрами. Они были придуманы для работы на одном ядре, без нормальных (оптимизированных и простых) инструментов параллелизации кода
То, что я назвал выше - признак старых языков. Go и Rust под эту категорию не подходят, потому что к моменту их создания, многоядерные процессоры уже были... были. За счёт этого, они относительно просто и эффективно работают с многопоточностью (жрут меньше памяти, работают быстрее, работать с ними программисту проще)
Технологическое будущее за нативной многопоточностью
Ссылка на оригинальный пост: https://t.me/sh1nke9/328
Показать полностью
1