Запустили опрос python-разработчиков про типизацию - в авторах опроса Astral, JetBrains, Microsoft, Meta, discuss.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

С 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-сообщества. Учитывая, что с большинством тех, чьи каналы в папке я знаком лично, на кого-то итак был подписан - рекомендую - 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

Пару недель назад я писал про то, насколько больше 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

Есть такой язык - Mojo:

• синтаксически он близок к python
• дает возможность вызывать и исполнять питоновские библиотеки через cpython-рантайм (я не уверен, что это production-схема
• расходы на конвертацию и GIL никуда не деваются, но тем не менее)
• при этом сам язык компилируемый - есть и JIT, и AOT-сборка в бинарник
• работает с gpu из коробки

и в принципе выглядит довольно интересно.

И вот на прошлой неделе вышла версия 1.0 языка, то есть предполагается, что он достаточно стабилизировался. А на днях его заопенсорсили под apache 2.0 лицензией. Я его трогал совсем немного - когда сделали возможность вызова python-библиотек, но сейчас кажется хороший повод пойти поиграться. https://www.modular.com/blog/mojo-open-source

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

Казалось бы, что может быть проще, чем разбить текст на строки? Может быть, кто-то еще помнит про \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 появилась отдельная страница со сложностью операций над встроенными типами. Списки, словари, множества, строки и прочее — с пояснениями, почему именно такая сложность и какие есть нюансы.

Отдельно любопытно почитать примечания. Например, O(1) у добавления в список — амортизированная оценка: иногда приходится перевыделять память, и конкретная операция будет O(n). А у словарей поиск в среднем O(1), но при неудачных коллизиях может стать O(n). В общем, полезная шпаргалка, чтобы освежить в голове, сколько стоят привычные операции.

Ссылка https://docs.python.org/3.16/library/time-complexity.html

Друзья, у нас важное объявление!

Некоторые из вас помнят наши курсы 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.