PEP 727 который лично мне не нравится, скорее всего будет отклонен.
https://discuss.python.org/t/pep-727-documentation-metadata-in-typing/32566/181
https://discuss.python.org/t/pep-727-documentation-metadata-in-typing/32566/181
Discussions on Python.org
PEP 727: Documentation Metadata in Typing
I ask for your guidance about how to proceed. As I previously mentioned, my recommendation is to abandon the use of Annotated for documentation and build on the existing docstring mechanisms that are supported by existing tools. Here’s another idea that…
https://discuss.python.org/t/three-month-suspension-for-a-core-developer/60250/4
Как вы уже могли слышать, роль основного разработчика была приостановлена для Тим Питерса(автор тимсорта в питоне) на 3 месяца. И вот вчера появляется этот комментарий от мейтнейнера енамов. Интересно, что будет дальше
Как вы уже могли слышать, роль основного разработчика была приостановлена для Тим Питерса(автор тимсорта в питоне) на 3 месяца. И вот вчера появляется этот комментарий от мейтнейнера енамов. Интересно, что будет дальше
https://discuss.python.org/t/calling-for-a-vote-of-no-confidence/61557/1
TL;DR: один из core developer'ов призывает к роспуску состава текущего руководящего совета. Все это связано с временной отставкой Tim Peters (пост выше)
TL;DR: один из core developer'ов призывает к роспуску состава текущего руководящего совета. Все это связано с временной отставкой Tim Peters (пост выше)
Discussions on Python.org
Calling for a Vote of No Confidence
According to the guidance in PEP 13, I am calling for a vote of no confidence for the entire council. This motion is based on their recent action of suspending a core developer in which they withheld critical information: The core developer’s name. Without…
CPython notes
Идея нового алгоритма сборщика мусора (скорее всего, будет реализована): https://github.com/faster-cpython/ideas/issues/613 В итоге +3-4% по перфомансу
https://discuss.python.org/t/incremental-gc-and-pushing-back-the-3-13-0-release/65285
В итоге этот новый сборщик мусора ревертят, из-за ухудшения по производительности в определенных сценариях... sphinx build стал тратить в 3 раза больше времени с этим сборщиком мусора
В итоге этот новый сборщик мусора ревертят, из-за ухудшения по производительности в определенных сценариях... sphinx build стал тратить в 3 раза больше времени с этим сборщиком мусора
Discussions on Python.org
Incremental GC and pushing back the 3.13.0 release
I’m a little [1] concerned with the impact of the incremental GC change in 3.13, which recently showed up (Incremental GC means that Sphinx is significantly slower in 3.13 than in 3.12 · Issue #124567 · python/cpython · GitHub). It’s not clear that the incremental…
Релизнулся питон 3.13!
Скачать можно тут: https://www.python.org/downloads/release/python-3130/
Что нового: https://docs.python.org/3.13/whatsnew/3.13.html
Скачать можно тут: 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
https://discuss.python.org/t/python-3-8-is-now-officially-eol/66983
Discussions on Python.org
Python 3.8 is now officially EOL
PEP 569 updated and marked as final. The Downloads page and the devguide updated. The branch is deleted, and a new 3.8 tag is placed in its stead for posterity. Thanks, 3.8. You were a good one. You brought us assignment expressions, and with that, the Steering…
Так же как и когда-то был опубликован PEP для JIT (уже после того как его смержили 😅), теперь опубликован PEP для нового REPL: https://peps.python.org/pep-0762/
Python Enhancement Proposals (PEPs)
PEP 762 – REPL-acing the default REPL | peps.python.org
One of Python’s core strengths is its interactive mode, also known as the Read-Eval-Print Loop (REPL), or the Python console, or the Python shell. This PEP describes the new implementation of this functionality written in Python. The new REPL released i...
Предложение об отказе от daemon-тредов:
https://discuss.python.org/t/getting-rid-of-daemon-threads/68836
https://discuss.python.org/t/getting-rid-of-daemon-threads/68836
Discussions on Python.org
Getting Rid of Daemon Threads
Daemon threads are a regular source of pain in core development and have been for years. I’d like to get rid of them. The impact on the Python community is the deciding factor; I suspect low impact but may be wrong. Your feedback will help. Proposal …
CPython notes
https://discuss.python.org/t/calling-for-a-vote-of-no-confidence/61557/1 TL;DR: один из core developer'ов призывает к роспуску состава текущего руководящего совета. Все это связано с временной отставкой Tim Peters (пост выше)
Uncle Timmy’s Public Blog
Mea Culpa
Question everything. Love everyone.
Был смержен тред-локал байткод - https://github.com/python/cpython/pull/123926
Зачем это нужно и как это связано с nogil aka free-threaded?
Напомню, что в версии 3.11 был добавлен так называемый <адаптивный> интерпретатор, который умеет в специализацию.
Типичная операция
Адаптивный интерпретатор "подстраивается" под ситуации когда у вас достаточно много случаев в коде когда в операции
Так вот, в случае с nogil сборкой адаптивный интерпретатор не является потокобезопасным, что делало nogil сборку действительно медленнее(потому что специализация была выключена в nogil сборке). Pull request отмеченный выше делает адаптивный интерпретатор потокобезопасным и вместе с этим у
Зачем это нужно и как это связано с nogil aka free-threaded?
Напомню, что в версии 3.11 был добавлен так называемый <адаптивный> интерпретатор, который умеет в специализацию.
Типичная операция
x + y в обычном случае превращается в BINARY_OP опкод, который делает x.__add__(y), что несомненно не очень-то и дешево, так как надо производить лукап __add__ и прочие связанные с этим операции.Адаптивный интерпретатор "подстраивается" под ситуации когда у вас достаточно много случаев в коде когда в операции
x + y оба операнда являются интами, и тогда можно сэкономить на лукапе и дергать специализированную сишную функцию для сложения интов, которая не производит никакого лукапа атрибутов, и именно на этом мы выигрываем по производительности.Так вот, в случае с nogil сборкой адаптивный интерпретатор не является потокобезопасным, что делало nogil сборку действительно медленнее(потому что специализация была выключена в nogil сборке). Pull request отмеченный выше делает адаптивный интерпретатор потокобезопасным и вместе с этим у
codeobject появляется атрибут co_tlbc :)