Питонические атаки
1.19K subscribers
183 photos
4 videos
1 file
459 links
Всяческие заметки про программирование на Python и другие весёлые истории.
Download Telegram
В продолжение про float и его погрешности.

Питон при отображении чисел с плавающей точкой обычно успешно отбрасывает погрешность, так что мы как правило видим красивые ровные числа:

>>> 0.1
0.1

Но это число нельзя точно представить в двоичном виде, в любом случае это будет лишь аппроксимация, приближение. Так что то, что показал питон — это лишь округление, это чтобы не пугать людей. Можно посмотреть на точное значение, которое хранится внутри float, например, при помощи конвертации числа в decimal.Decimal:

>>> Decimal.from_float(0.1)
Decimal('0.1000000000000000055511151231257827021181583404541015625')

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

Вернёмся к нашим числам с плавающей точкой. float достаточно точно может описывать числа вокруг нуля, но чем дальше, тем сильнее падает точность аппроксимации. Например, между вот такими числами разница во float уже не представима:

>>> Decimal.from_float(10.0 ** 16)
Decimal('10000000000000000')
>>> Decimal.from_float(10000000000000000.1)
Decimal('10000000000000000')

В какой-то момент float вообще перестаёт мочь представлять точно даже целые числа, например, 10 ** 22 всё ещё представимо:

>>> Decimal.from_float(10.0 ** 22)
Decimal('10000000000000000000000')

А вот 10 ** 23 уже нет:

>>> Decimal.from_float(10.0 ** 23)
Decimal('100000000000000008388608')

Бабах! Ошибка на восемь миллионов, но это самая точная аппроксимация, которую можно выразить на 64 битах, выделенных под число (на самом деле, мантисса числа — самая важная часть — занимает лишь 53 бита). И это мы ещё даже никаких операций над числами не делали, просто их создаём.

Не знаю, есть ли на планете человек, у которого на счету лежит 10 ** 23 денег. Возможно, если конвертировать все накопления Джефа Безоса (самый богатый человек) в иранские риалы (самая дешевая валюта)... 🤔 Остаётся только надеяться, что его банк не использует float для хранения баланса.

Ну, короче, вы поняли, какого порядка могут быть погрешности, если использовать float с большими числами.

Вот тут есть некоторые объяснения странностей float: https://docs.python.org/3/tutorial/floatingpoint.html
На Reddit проходит AMA сессия (ask me anything) с создателем и мейнтейнерами Black — это такой форматтер кода.

Например, оттуда я узнал, что Black все ещё парсит код при помощи старого LL-1 парсера, в то время как CPython с версии 3.10 уже полностью переключился на более продвинутый PEG-парсер по умолчанию (в 3.9 его можно было включить через флаг), благодаря чему и стали возможны все эти выкрутасы со сложными синтаксическими конструкциями, типа паттерн-матчинга. Похоже, Black был одной из причин, по которым было решено переписать парсер, но теперь у самого Black из-за этого будут сложности — придётся переписать много кода, чтобы поддержать 3.10.

https://www.reddit.com/r/Python/comments/plvtlx/were_the_core_team_behind_the_popular_python/
Цитата дня
Интересная серия постов в блоге StackOverflow про разработку софта в SpaceX — для управления ракетами, спутниками Starlink и всякими внутренними процессами, типа цепочек поставок и сборки аппаратов на конвейерах. Статьи в популярном стиле, технических подробностей не слишком много, но всё равно интересно.

Самые ответственные части пишутся, конечно, на C++ — например, ПО, которое работает непосредственно на ракетах и спутниках, потому что там нужно быстро реагировать и принимать решения. Но в местах, где производительность не критична, а также для прототипирования, используется Python. Ещё используются PostgreSQL, Docker, Kubernetes, Angular. Раньше было много чего на MS стэке — SQL Server, ASP.NET и прочее, но от этого решили отказаться в пользу открытых продуктов.

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

Забавно, что чуваки запускают аппараты в космос, а технологический стэк плюс-минус такой же, как и у нас, простых смертных.

https://stackoverflow.blog/tag/software-in-space/
Ещё одна штука для форматирования кода. Она даже ещё более лютая, чем black. Объединяет в себе следующие тулзы:

* autoflake — удаляет неиспользуемые импорты и переменные;
* pyupgrade — применяет кучу рефакторингов и эвристик против использования старых и плохих подходов, заменяя их на новые и правильные;
* isort — сортирует импорты;
* black — форматирует код;
* pybetter, teyit, com2ann — применяет тривиальные рефакторинги, заменяет устаревшие методы на новые, делает из комментариев # type: int нормальные тайп-аннотации.

При этом штука не даёт вообще ничего настроить. Максимально тоталитарно!

https://github.com/Zac-HD/shed
Ещё один комбайн для форматирования кода ufmt = black + usort (сортировалка импортов).

https://github.com/omnilib/ufmt

Оттуда я узнал про эту интересную альтернативу isort. В отличии от isort, оно не меняет форматирование (просто меняет импорты местами, не меняя сам код, не расставляя скобки и переносы строк) и не делает опасных рефакторингов (не меняет положение импортов относительно другого кода). Точно так же бьёт импорты на три секции — stdlib, 3rdparty, 1stparty.

https://github.com/facebookexperimental/usort
Кстати, PSF закрыл ещё одну свою вакансию, и теперь у нас есть оплачиваемый фулл-тайм проджект менеджер, который будет заниматься развитием PyPI и экосистемой пакетов в целом!

Эта позиция создана по инициативе и при финансовой поддержке со стороны Bloomberg. Они закоммитились выплачивать гранты минимум 2 года, так что и эта должность вероятно тоже просуществует как минимум пару лет.

https://pyfound.blogspot.com/2021/08/shamika-mohanan-has-joined-psf-as.html
Минутка сомнительного контента.

Я продолжаю заниматься цифровой археологией, изучая источники эпохи Великого Перехода на Python 3 (примерно 2010 — 2021 гг. н.э.). Без сомнения, это был очень болезненный процесс. Я прочитал уже много критики, но некоторые статьи меня до сих пор могут удивить. Например, вот этот пост "The Case Against Python 3" от Зеда Шоу (Zed Shaw).

https://learnpythonthehardway.org/book/nopython3.html

Цитаты:

> THERE IS A HIGH PROBABILITY THAT PYTHON 3 IS SUCH A FAILURE IT WILL KILL PYTHON.

> the Python project uses propaganda, social pressure, and marketing to convince you to use it

В статье есть валидные претензии по поводу того, что переделка строк из байтовых в текстовые действительно создала много сложностей при переходе. Но в основном статья, конечно, полный треш с беспочвенным нытьём, теориями заговора и питонистами-рептилоидами. В одной из предыдущих версий статьи автор даже на серьёзных щах утверждал, что Python 3 не полон по Тьюрингу (или он так шутит, хз).

В интернете тогда знатно бомбануло по поводу этого поста. Вот здесь есть качественный ответ с разбором по пунктам: https://eev.ee/blog/2016/11/23/a-rebuttal-for-python-3/

В итоге автор всё-таки адаптировал свою книгу Learn Python The Hard Way для Python 3, хотя сопротивлялся до 2017 года. Кажется, после этого поста книге и перестали доверять в сообществе, её перестали рекомендовать, а автор в итоге закрыл её под пейволлом, хотя раньше она была доступна полностью бесплатно. Жаль, такие драмы никогда не идут на пользу общему делу. Но в них интересно в последствии копаться, хах.

Статью вряд ли можно воспринимать всерьёз, но это похоже на крик души, и это что-то говорит о том переходном периоде. Неужели переход был настолько болезненным, что когда-то действительно казалось, что третья версия убьёт язык? Что проще уже перейти на что-то другое, чем на Python 3? Неужели действительно казалось, что PSF пытается продавить миграцию через пропаганду, чтобы заставить пользоваться сломанной версией языка?

Деды, если вы ещё живы, расскажите как оно было на самом деле? Что вы скажете о миграции на Python 3?
Ого, оказывается Python активно используется при производстве фильмов и всяких анимационных мультфильмов.

Чувак, который работал в Sony Pictures, в частности над Spider-Man: Homecoming, рассказывает как Python помогает на разных этапах производства фильма. Там ещё есть ссылки на целую серию постов про разбор разных фильмов. Чувак даже сделал курс на Udemy, где обучает как скриптовать в Maya на питоне.

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

https://www.gfx.dev/python-for-feature-film
Don Syme (создатель языка F#) учит Гвидо писать функциональщину. Забавно, что два дизайнера языков собрались, и один презентует свой язык другому.

Напомню, что Гвидо в одном из предыдущих интервью говорил, что он никогда не увлекался функциональным программированием. Судя по всему, в этом видео он увидел F# впервые (я тоже).

Хорошее вводное видео в F#. Оттуда я узнал, что на нём можно делать фуллстэк — можно бабахать бэкенды, и даже есть какая-то забавная обёртка над React, так что можно делать SPA фронтенды.

https://www.youtube.com/watch?v=e2J9PGC-K1E
Forwarded from DevBrain
Годнота подъехала. Подробная статья про FastAPI, асинхронный SQLAlchemy через новую балалайку SQLModel: https://testdriven.io/blog/fastapi-sqlmodel/
Java 17 подрезает Python 3.10 на финишной прямой (кстати, релиз запланирован на 4 октября) и релизит паттерн-матчинг на две недели раньше 😅

Забавно, что паттерн-матчинг уже был в Haskell в 1990 году. А Википедия говорит, что были и другие языки с паттерн-матчингом до Haskell, начиная с 1955-х годов. Получается, теорию разработали ещё раньше.

После хаскеля потребовалось ещё 30 лет, чтобы эта фича из разряда «снова эти наркоманы что-то выдумали» перешла в «нам всем это очень надо». Думаю, что успех Rust тут сыграл не последнюю роль.

Это замечательно иллюстрирует, насколько медленно к нам в мейнстримные языки проникают инновации. Говорят, что для теории языков программирования — это норма. Ребята там сейчас придумывают вещи, которые до нас дойдут лишь лет через 20-30, если повезёт.

Но похоже, что скоро паттерн-матчинг будет везде! Например, есть пропозал для JS.
День Docker'а на канале.

Все, кто пользуется Docker, знают, что он кэширует сборку слоями, команда за командой. Но знали ли вы, что с недавних пор помимо кэширования слоями можно ещё закэшировать отдельную папку? Например, таким образом можно заставить работать встроенный в pip кэш и не перекачивать все ваши 1000 пакетов старых зависимостей из PyPI каждый раз, если вы вдруг решили добавить ещё одну новую.

Магия активируется вот таким набором заклинаний:

1. устанавливаем переменную окружения, чтобы задействовать новый механизм сборки:

$ export DOCKER_BUILDKIT=1

2. в начало Dockerfile добавляем строчку с указанием на новый синтаксис:

# syntax = docker/dockerfile:1.3

3. в команду RUN добавляются новые аргументы:

RUN --mount=type=cache,target=/root/.cache \
pip install -r requirements.txt

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

Как минимум, это удобно для сборки образов на локальной машине. Если в CI настроить сохранение кэшей Docker'а между запусками, то это тоже будет работать.

https://pythonspeed.com/articles/docker-cache-pip-downloads/

#синийкит #docker
Ещё одна классная фича, доступная с новым синтаксисом Dockerfile — многострочные команды, т.е. поддержка полноценных скриптов! Умные люди называют такой синтаксис heredoc. Теперь можно больше не писать эти дурацкие амперсанды и бэкслеши в конце каждой строчки в длинной команде.

Раньше:

FROM debian
RUN apt-get update \
&& apt-get install -y vim

Сейчас:

# syntax=docker/dockerfile:1.3-labs
FROM debian
RUN <<eot bash
apt-get update
apt-get install -y vim
eot

А ещё таким образом можно запускать даже скрипты на python (да и вообще любые скрипты). Скрипт выполнится, результаты его работы останутся в образе, но сам он никогда туда не попадёт, потому что он вообще не сохраняется на диск. Пока не придумал, зачем такое может пригодиться, но прикольно:

# syntax=docker/dockerfile:1.3-labs
FROM python:3.9-slim-buster

RUN python3 <<EOF
for i in range(10):
with open(f"/{i}.txt", "w") as f:
f.write(f"File {i}")
EOF

Источник: https://twitter.com/iximiuz/status/1436357612740694016?s=20

#синийкит #dockerо
Forwarded from Geeks (жук невывожук)
Вышла версия 1.0.0.beta0 python-библиотеки httpx. Это - достаточно известная библиотека для осуществления HTTP-запросов, и она предоставляет разработчику как синхронное API, так и асинхронное. Использую её достаточно давно и всем устраивает. Как приятный бонус - вызовы полностью идентичны таковым в широко распространенной библиотеке requests. Тех, кто использует тайпинг, порадует то, что библиотека полностью аннотирована.

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

Если хочется быстро попробовать, то скачиваем пакет:

pip install --pre 'httpx[cli]'

И пробуем:

httpx --verbose https://httpbin.org/json

Ссылка на GitHub библиотеки https://github.com/encode/httpx
Ну и ещё одна фича — команда COPY в Dockerfile тоже получила поддержку heredoc.

# syntax=docker/dockerfile:1.3-labs
COPY <<EOF /usr/share/nginx/html/index.html
<html>
<head></head>
<body>Hi!</body>
</html>
EOF

Теперь можно разные небольшие файлы создавать прямо в Dockerfile.

Источник: https://twitter.com/iximiuz/status/1436361338696183815?s=20

#синийкит #docker
Знаю, что на канале есть некоторое количество пользователей OpenWRT — свободной прошивки для роутеров на линуксе.

Если вдруг пропустили, то вышла новая версия 21.02. Пора обновляться!

Попробую обновиться и по возможности адаптирую пост про точечный обход блокировок. Хотя, почитав последние грустные новости про суверенный интернет и ТСПУ, я уже начинаю склоняться к более простому и надёжному варианту — пересесть на VPN полностью.

#оффтоп