Хитрый Питон

Друзья, у нас важное объявление! Некоторые из вас помнят наши курсы Learn Python - когда-то они запускались в оффлайне и были отличной точкой входа для новичков. В последнее время спрос на курсы по программированию по понятным причинам упал, однако необходимость "прокачиваться" тем, кто уже в профессии, осталась. Помимо этого, как никогда актуален "живой" формат - именно сегодня крайне важна энергетика, которую получаешь от общения с единомышленниками в оффлайне. Именно эта идея лежала в основе Moscow Python, когда мы запускали наши митапы в 2012-м году, однако мы решили пойти дальше и сегодня объявляем о запуске Moscow Python Pro - это и серия мероприятий, и своего рода "сообщество внутри сообщества". Главными лицами Moscow Python Pro являются его резиденты. Это люди, с которыми вы хорошо знакомы по митапам и конференциям. Именно в рамках наших мероприятий вы получаете возможность близкого общения с этими людьми и получения от них ответов на ваши вопросы в неформальной обстановке. Старт серии мероприятий Moscow Python Pro знаменуют 2 круглых стола на тему "Навыки сильного разработчика в эпоху ИИ". Круглый стол 06.10, участники: - Александр Ковалев (Ozon Tech, Руководитель группы разработки) - Александр Полищук (МТС Веб Сервисы, Руководитель разработки Дата платформы) - Сурен Хоренян (Яндекс, Старший разработчик) - Михаил Васильев (Райффайзенбанк, Старший инженер по машинному обучению) Круглый стол 09.10, участники: - Алексей Жиряков (Сбер, Исполнительный директор в дивизионе «Развитие генеративного ИИ») - Максим Богуславский (ООО «Альфа-функция», Генеральный директор) - Денис Аникин (Райффайзенбанк, Техлид) Ведущий обоих мероприятий: Валентин Домбровский, сооснователь Moscow Python. Подробности о мероприятиях и "перках" для участников читайте по ссылкам выше. Да, это платно, но мы надеемся, что это позволит нам развивать сообщество дальше и придумывать для вас новые крутые идеи. Отметим также, что до конца этой недели доступна специальная ранняя цена (а также специальная цена для тех, кто решит сходить на оба круглых стола сразу). До скорых встреч и да пребудет с вами Python! --------------------- NB: Если вы получили это сообщение от друга или прочитали его в дружеском нам канале, подписывайтесь на @moscow_python, чтобы следить за новостями Moscow Python.

В документации Python появилась отдельная страница со сложностью операций над встроенными типами. Списки, словари, множества, строки и прочее — с пояснениями, почему именно такая сложность и какие есть нюансы. Отдельно любопытно почитать примечания. Например, O(1) у добавления в список — амортизированная оценка: иногда приходится перевыделять память, и конкретная операция будет O(n). А у словарей поиск в среднем O(1), но при неудачных коллизиях может стать O(n). В общем, полезная шпаргалка, чтобы освежить в голове, сколько стоят привычные операции. Ссылка https://docs.python.org/3.16/library/time-complexity.html

В эту пятницу в 14:00 (по мск) обсудим новости августа в прямом эфире Moscow Python Podcast 🎙 Вместе Гришей Петровым разберём самые интересные новости Python последних недель: 🟤PEP 805 — Safe Parallel Python - альтернатива NoGil или дополнение к нему? 🟤PEP 841: новый синтаксис frozen для создания неизменяемых коллекций — frozenset и frozendict. PEP активно обсуждается, а среди его авторов — Никита Соболев; 🟤Django Developers Survey 2026: посмотрим, что нового можно узнать о сообществе и разработчиках Django; 🟤Django переходит на ежегодный цикл релизов: Django 6.2 LTS станет последним релизом со старой нумерацией, а в январе 2028 года нас ждёт Django 2028. Заодно обсудим новую модель поддержки версий; 🟤Документация Python теперь доступна на русском: перевод уже готов на 69%, а ключевые разделы документации переведены полностью; 🟤И пара других новостей. 📍 Когда и во сколько: 4 сентября в 14:00 по Москве. ➡️ Подключайтесь к эфиру или смотрите запись на YouTube, VK или Rutube.

Казалось бы, что может быть проще, чем разбить текст на строки? Может быть, кто-то еще помнит про \n, \r и \r\n, и в старые времена надо было знать или угадывать, что используется в файле в зависимости от системы. Мы привыкли, что в python обычно все просто - splitlines()`/`split('\n') и готово, дальше под капотом работает магия. На самом деле все, конечно, гораздо сложнее 🙂 Джеймс Беннет написал отличный разбор, как все работает сейчас, почему и откуда это все взялось. Началось все с ASCII и телетайпов: LF (`0x0A`) двигал бумагу вниз, CR (`0x0D`) возвращал каретку. Два символа нужны, потому что механике требуется время, чтобы каретка успела доехать. Потом терминалы стали виртуальными, необходимость отпала, и все разбежались кто куда: CP/M → DOS → Windows оставили CR LF, Multics → Unix взяли только LF, Apple и Commodore - только CR. В питон еще в версии 2.3 завезли PEP 278 - universal newlines. Но так-то в ASCII есть еще FF (form feed, `0x0C`) и VT (vertical tab, `0x0B`) - они как бы не "новая строка", но по факту переводят вывод на другую строку. Плюс NEL (`0x85`), который завели для совместимости с IBM-овской кодировкой EBCDIC, где был свой символ для перевода строки. Дальше Юникод добавил U+2028 LINE SEPARATOR и U+2029 PARAGRAPH SEPARATOR, потому что обычный newline стал двусмысленным: текстовые редакторы с автопереносом начали использовать его как разрыв абзаца, а не строки. Самое неожиданное - последние три: U+001C, U+001D, U+001E, они же ASCII-шные FILE, GROUP и RECORD SEPARATOR, которыми когда-то разделяли записи в данных. К разрыву строк они отношения не имеют, а попали в список через алгоритм для текста со смешанным направлением письма (слева направо и справа налево). Если, например, в тексте на арабском вставка цитаты на английском, направление переключается спецсимволом, и действует он до конца абзаца. А у этих трех разделителей в свойствах как раз прописано "конец абзаца" - вот они и оказались в одном списке с настоящими переводами строк. Сейчас это все собрано в splitlines(). А практический вывод простой: splitlines() и split('\n') - это не одно и то же. Если в данных попадется \x1c или \u2028 (а в выгрузках из всяких легаси-систем они попадаются), результат будет разный. Для парсинга структурированных форматов лучше явно указывать разделитель. Оригинал https://www.b-list.org/weblog/2026/aug/10/newlines/

Пока я был в отпуске и путешествовал, вышел перевод документации Python на русский. Звучит круто, но на самом деле полностью переведены только core-разделы Tutorial, Built-in Functions and Dealing with Bugs, заметная часть документации все еще на английском. Посмотреть на прогресс перевода (сейчас 69%) и присоединиться к проекту можно здесь https://explore.transifex.com/python-doc/python-newest/

Есть такой язык - Mojo: - синтаксически он близок к python - дает возможность вызывать и исполнять питоновские библиотеки через cpython-рантайм (я не уверен, что это production-схема - расходы на конвертацию и GIL никуда не деваются, но тем не менее) - при этом сам язык компилируемый - есть и JIT, и AOT-сборка в бинарник - работает с gpu из коробки и в принципе выглядит довольно интересно. И вот на прошлой неделе вышла версия 1.0 языка, то есть предполагается, что он достаточно стабилизировался. А на днях его заопенсорсили под apache 2.0 лицензией. Я его трогал совсем немного - когда сделали возможность вызова python-библиотек, но сейчас кажется хороший повод пойти поиграться. https://www.modular.com/blog/mojo-open-source

Пару недель назад я писал про то, насколько больше security-отчетов теперь приходит для CPython по сравнению с предыдущими годами. Казалось бы - берешь llm, она пишет тебе патч - и готово, profit. И тут как раз 1password опубликовали исследование, которое показывает, что это пока так не работает. Они сгенерировали более 6000 патчей для 6 разных уязвимостей с помощью opus 4.8 и chatgpt 5.5, обе в версии для security-специалистов (т.е. там были убраны часть ограничений). Результат? Только 26% патчей полноценно устранили уязвимость. Ещё 20,1% проблему закрыли, но работа приложения изменилась, читай "побочные эффекты". Самое забавное, в 2,1% случаев проблема не была устранена, так еще и появилась новая уязвимость. Хуже того, в трети "успешных" 20,1% на самом деле llm-ка фиксила не первопричину проблемы, а конкретный пример атаки, описанный в промпте. Вывод? Llm-ки очень удобны и могут ускорить разработку - но и голову тоже нужно включать и смотреть, что там интеллект нагенерил - ревьюить, править, тюнить. Ссылка на статью: https://1password.com/blog/why-ai-generated-patches-still-require-human-review

Вчера пишет мне Никита Соболев - так и так, собираем папку с каналами python-сообщества. Учитывая, что с большинством тех, чьи каналы в папке я знаком лично, на кого-то итак был подписан - рекомендую - https://t.me/addlist/o2_hXmp5nSUyODNi Для тех, кто уперся в лимит телеги по папкам, вот просто список каналов: • https://t.me/opensource_findings • https://t.me/goduniblog • https://t.me/cpython_notes • https://t.me/nkhitrov_blog • https://t.me/fastnewsdev • https://t.me/pylounge • https://t.me/blog_pogromista • https://t.me/moscow_python • https://t.me/tricky_python • https://t.me/pymineral • https://t.me/t0digital • https://t.me/grigorycode

С 2028 года Django переходит на ежегодные релизы, при этом каждый такой релиз будет LTS с тремя годами поддержки. С одной стороны, разработка вроде как замедлится, а с другой стороны, с крупными релизами больше шансов протащить крупные системные изменения. Плюс, конечно, тем, кто поддерживает сайты на Django, не придётся больше заморачиваться с LTS — не LTS. Django 6.2 LTS в апреле 2027 станет последним релизом со "старой" нумерацией, в январе 2028 выйдет уже Django 2028. https://www.djangoproject.com/weblog/2026/aug/10/annual-release-cycle/

Запустили опрос python-разработчиков про типизацию - в авторах опроса Astral, JetBrains, Microsoft, Meta, discourse.python.org - т.е. очень многие из тех кто реально занимается типаии/туллингом. Это ежегодная история, предыдущий отчет тут https://engineering.fb.com/2025/12/22/developer-tools/python-typing-survey-2025-code-quality-flexibility-typing-adoption/ - мы кажется обсуждали его в подкасте. Если вы активно используете аннотации типов - сходите пройдите, важно давать обратную связь разработчикам, я уже прошел https://www.surveymonkey.com/r/python_typing

Уже завтра в 14:00 (по мск) обсудим новости июля в прямом эфире Moscow Python Podcast 🎙 Разберём самые интересные события последних недель: 🟤 PEP 836: новый план развития JIT-компилятора для CPython; 🟤 Ruff 0.16: теперь по умолчанию включены 413 правил вместо 59; 🟤 GitHub усиливает безопасность CI; 🟤 Релиз Django 6.1; 🟤 Обсудим статью In Defense of Not Understanding Your Codebase. 📍 Когда и во сколько: 7 августа в 14:00 по Москве. ➡️ Подключайтесь к эфиру или смотрите запись на YouTube, VK или Rutube.

Вышел релиз Django 6.1. Изменений не очень много: - QuerySet.fetch_mode позволяет более гибко управлять тем, что происходит при обращении к незагруженному полю модели - делать запрос в базу, делать запрос загружая связанные сущности одним запросом или выдавать исключение. Выглядит как действительно полезная фича - on_delete для ForeignKey теперь можно перевесить на уровень базы данных через SQL ON DELETE, раньше это делалось python-логикой - В ORM добавлены функции для генерации UUID v4 и UUID v7 на стороне БД - Всякие улучшения для Content Security Policy, настройки отправки email теперь конфигурируются через словарь и много всяких других мелочей Полный ченджлог тут https://docs.djangoproject.com/en/6.1/releases/6.1/

Вместе с прогрессом llm-ок растет нагрузка на мейнтенеров проектов, это не новость и мы много раз обсуждали это в подкасте. Но вот подъехала статья с нитересными графиками по нагрузке именно связанноы с безопасностью: - Security-отчеты на github - ~40 за весь 2025 и уже 175 за первую половину 2026 - Полноценные CVE - ~20 за 2025 и столько же только за первую треть 2026, т.е. за весь год предполагается рост в три раза То есть рост нагрузки очень значительный, сама статься состоит почти из одних графиков https://hugovk.dev/blog/2026/security-line-goes-up/

Поддержка free-threading в библиотеках сейчас один из ключевых блокеров перехода на free-treading. Поэтому я с интересом читаю статьи, которые публикуют на этот счет разработчики библиотек - не то чтобы мне это было нужно для работы, просто очень интересно. На днях наткнулся на статью, про оптимизацию NumPy - проблема была в том, что с отключенным GIL, ThreadPoolExecutor все равно работал медленнее, чем ProcessPoolExecutor. Если вам такое интересно - рекомендую почитать, но если кратко: - Убрали локи там, где можно было обойтись без них - Где-то перешли на immortal-объекты, чтобы перестать дергать счетчик ссылок - Пересели с системного malloc/free на cpython-овский аллокатор, который лучше масштабируется на большое количество потоков В результате бенчмарк вместо 44 секунд на 32 потоках начал отрабатывать за 1,5 секунды (при использовании процессов - 6 секунд). Подробнее в статье - https://labs.quansight.org/blog/scaling-numpy-on-free-threaded-python

Вышла библиотека django-orjson, которая позволяет легко перевести Django и DRF на быстрый orjson. В комплекте — JsonResponse, renderer и parser для DRF и даже сериализатор для сессий. В принципе, идея не новая: мы у себя перевели DRF на orjson ещё года четыре назад. Но с готовым пакетом это будет гораздо проще сделать. Тем, у кого плюс-минус нагруженный проект или просто большие JSON-запросы и ответы, рекомендую присмотреться: https://adamj.eu/tech/2026/07/15/introducing-django-orjson/

GitHub запустил пару полезных фич для безопасности CI. Во-первых, Malware Alerts. Эта штука проверяет, нет ли зависимостей проекта в базе OpenSSF Malicious Packages, и, если находит совпадение, присылает алерт. Глобально включить её пока нельзя — только отдельно для каждого репозитория. Я у себя уже включил, вот тут инструкция https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-malware-alerts Вторая фича - автоматическое обнаружение и блокировка небезопасных CI-пайплайнов. Если workflow выглядит потенциально вредоносным, GitHub не запускает его, пока участник с правами на запись не подтвердит запуск. Пока это работает только для публичных репозиториев. Если интересно подробнее почитать, как могут выглядеть подобные атаки, вот хороший разбор: https://www.stepsecurity.io/blog/introducing-secret-exfiltration-protection-for-github-actions

Вышла новая версия Ruff 0.16. Казалось бы, минорный релиз, но на самом деле нет. Теперь по умолчанию включено 413 правил вместо 59, поэтому, если в конфиге у вас не зафиксирован список правил, используемых на проекте, вас ждёт сюрприз. Ради интереса прогнал Ruff на своём пет-проекте, где до обновления всё было зелёненьким. После перехода на 0.16 получил: Found 50 errors, 34 fixable. Пойду чинить 🙂 Если планируете обновляться на большой кодовой базе, сразу закладывайте время на фиксы. Ченджлог в блоге Astral: https://astral.sh/blog/ruff-v0.16.0

Прикольный проект — интерпретатор «старого» Бейсика на Python. Сам проект маленький, всего около 1000 строк, поэтому, если вам интересно немного разобраться в том, как работают интерпретаторы, рекомендую посмотреть: https://github.com/nedbat/acidica

Уже сегодня в 14:00 (по мск) обсудим новости июня в прямом эфире Moscow Python Podcast 🎙 Обсудим с Никитой Соболевым последние интересные релизы: 🟤Что нового будет в Python 3.15 🟤Django 6.1 Beta: главные изменения и новые возможности 🟤PEP 835: сокращённый синтаксис для метаданных Annotated 🟤Небезопасные подсказки кода: можно ли считать их уязвимостью? Основные ведущие: Михаил Корнеев и Григорий Петров 📍Когда и во сколько: 3 июля в 14:00 по Москве. Подключайтесь к удобной площадке Youtube / Rutube ➡️ Присоединяйтесь к эфиру или смотрите в записи на любой из площадок

Завтра, 10 июня обсудим новости мира Python в прямом эфире Moscow Python🎙 Перенесли выпуск с пятницы на эту среду, а всё остальное будет, как вы любите — обсудим новости с Мишей Корнеевым и Гришей Петровым. 📍Когда и во сколько: 10 июня в 14:00 по Москве. Подключайтесь к удобной площадке YouTube / Rutube / на VK Видео ссылка будет позже