PEP 727 который лично мне не нравится, скорее всего будет отклонен.

https://discuss.python.org/t/pep-727-documentation-metadata-in-typing/32566/181

https://discuss.python.org/t/three-month-suspension-for-a-core-developer/60250/4

Как вы уже могли слышать, роль основного разработчика была приостановлена для Тим Питерса(автор тимсорта в питоне) на 3 месяца. И вот вчера появляется этот комментарий от мейтнейнера енамов. Интересно, что будет дальше

https://discuss.python.org/t/calling-for-a-vote-of-no-confidence/61557/1

TL;DR: один из core developer'ов призывает к роспуску состава текущего руководящего совета. Все это связано с временной отставкой Tim Peters (пост выше)

Теперь я участник Python Core Team.
https://discuss.python.org/t/vote-to-promote-kirill-podoprigora/63503/5

https://discuss.python.org/t/incremental-gc-and-pushing-back-the-3-13-0-release/65285

В итоге этот новый сборщик мусора ревертят, из-за ухудшения по производительности в определенных сценариях... sphinx build стал тратить в 3 раза больше времени с этим сборщиком мусора

Релизнулся питон 3.13!
Скачать можно тут: https://www.python.org/downloads/release/python-3130/
Что нового: https://docs.python.org/3.13/whatsnew/3.13.html

Вместе с этим, 3.8 более не поддерживается:
https://discuss.python.org/t/python-3-8-is-now-officially-eol/66983

Так же как и когда-то был опубликован PEP для JIT (уже после того как его смержили 😅), теперь опубликован PEP для нового REPL: https://peps.python.org/pep-0762/

Предложение об отказе от daemon-тредов:
https://discuss.python.org/t/getting-rid-of-daemon-threads/68836

План на 3.14 от faster-cpython team
https://github.com/faster-cpython/ideas/blob/main/3.14/README.md

(Cпасибо @serjflint!)

Питон самый популярный язык на гитхабе

Был смержен тред-локал байткод - https://github.com/python/cpython/pull/123926

Зачем это нужно и как это связано с nogil aka free-threaded?

Напомню, что в версии 3.11 был добавлен так называемый <адаптивный> интерпретатор, который умеет в специализацию.
Типичная операция x + y в обычном случае превращается в BINARY_OP опкод, который делает x.__add__(y), что несомненно не очень-то и дешево, так как надо производить лукап __add__ и прочие связанные с этим операции.
Адаптивный интерпретатор "подстраивается" под ситуации когда у вас достаточно много случаев в коде когда в операции x + y оба операнда являются интами, и тогда можно сэкономить на лукапе и дергать специализированную сишную функцию для сложения интов, которая не производит никакого лукапа атрибутов, и именно на этом мы выигрываем по производительности.

Так вот, в случае с nogil сборкой адаптивный интерпретатор не является потокобезопасным, что делало nogil сборку действительно медленнее(потому что специализация была выключена в nogil сборке). Pull request отмеченный выше делает адаптивный интерпретатор потокобезопасным и вместе с этим у codeobject появляется атрибут co_tlbc :)

https://trycinder.com/

:)

https://discuss.python.org/t/an-analysis-of-return-in-finally-in-the-wild/70633
Дискуссия о использования return в finally блоке. Вероятно, PEP 601 который предлагает запретить return/break/continue в finally блоке будет вновь рассмотрен.