Post #12
4.05K
Channel Public Channel
CP - Subscribers
- 2.39K
- Photos
- 11
- Videos
- 0
- Links
- 95
Showing posts older than #14 · Back to latest
Older Posts 9 shown
Post #11
2.37K
https://discuss.python.org/t/is-python-3-13-going-to-be-python-4/37490
TL;DR
Discussions on Python.org Python 3.13 alpha 1 contains breaking changes, what's the plan? Hi all, I haven’t followed CPython’s core discussions much since they (sadly) moved away from python-dev, so I ran into the C-API changes that were made for 3.13a1 with little prior warning. At least the shear amount of changes leaves me baffled. Hundreds… TL;DR
There will never be a Python 4.
- 👍 7
- 🌚 1
Post #10
2.44K
Руководящий совет языка принимает PEP 703 (nogil):
https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075
Стоит отметить, что изменения все таки могут быть отменены, если что-то пойдет не так.
Discussions on Python.org PEP 703 (Making the Global Interpreter Lock Optional in CPython) acceptance (Posted for the whole Steering Council.) As we’ve announced before, the Steering Council has decided to accept PEP 703 (Making the Global Interpreter Lock Optional in CPython) . We want to make it clear why, and under what expectations we’re doing so. It… https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075
Стоит отметить, что изменения все таки могут быть отменены, если что-то пойдет не так.
- 👍 6
- 🤔 1
Post #9
2.61K
Идея нового алгоритма сборщика мусора (скорее всего, будет реализована):
https://github.com/faster-cpython/ideas/issues/613
В итоге +3-4% по перфомансу
GitHub Incremental cycle GC · Issue #613 · faster-cpython/ideas The cycle GC takes about 10% of the runtime on our benchmark suite. This is already far too high, and with NoGIL it will get much worse. Currently, we perform an entire heap scan every N collection... https://github.com/faster-cpython/ideas/issues/613
В итоге +3-4% по перфомансу
- 🔥 8
- 🤔 2
- 🫡 2
Post #8
2.65K
Теперь я участник Python Triage Team.
https://github.com/python/core-workflow/issues/509
https://github.com/python/core-workflow/issues/509
- 🔥 27
- 👍 6
- 👏 2
Post #7
2.66K
Post #6
2.66K
К сообщению выше, стоит сказать что
Все это пришло вместе с pep-695.
Если смотреть с точки зрения лаконичности, этот пеп имеет смысл.
В основном, теперь просто не надо создавать тайпвары.
Окей, но не стоит забывать что у тайпваров можно было указать ко/контравариантность. А что с вариантностью в новом синтаксисе? Кстати, вот он -
тоже и для функций
И к сожалению (как минимум, моему) фичи вида +T -T ~T не доступны. То есть, в таком виде не укажешь вариантность типа.
В итоге, мы имеем <Автовариантность>. На чьи плечи она ложится? На плечи тайпчекеров.
Почему так сделали? Потому что тему вариантности посчитали достаточно сложной и запутанной.
Выводы делайте сами.
По перфомансу с точки зрения создания класса/функции с таким синтаксисом (именно создания класса/функции, а не создания инстанса/вызова функции).
Перфоманс в этом плане, конечно, упал. Байткод у классов/функций которые написаны в "новом стиле" чуть ли не в 2 раза длиннее. Но, так как создание класса/функции у нас происходит один раз, не то что бы это как-то влияло на общую картину(я думаю, что в кодогенерации, результат которой исполняется на лету, никто не использует тайпхинты)
А
type теперь у нас soft-keyword.Все это пришло вместе с pep-695.
Если смотреть с точки зрения лаконичности, этот пеп имеет смысл.
В основном, теперь просто не надо создавать тайпвары.
Окей, но не стоит забывать что у тайпваров можно было указать ко/контравариантность. А что с вариантностью в новом синтаксисе? Кстати, вот он -
class Foo[T: int]:
def method(self, arg: T) -> T:
return arg
тоже и для функций
def foo[T: int](arg: T) -> T:
return arg
И к сожалению (как минимум, моему) фичи вида +T -T ~T не доступны. То есть, в таком виде не укажешь вариантность типа.
В итоге, мы имеем <Автовариантность>. На чьи плечи она ложится? На плечи тайпчекеров.
Почему так сделали? Потому что тему вариантности посчитали достаточно сложной и запутанной.
Выводы делайте сами.
По перфомансу с точки зрения создания класса/функции с таким синтаксисом (именно создания класса/функции, а не создания инстанса/вызова функции).
Перфоманс в этом плане, конечно, упал. Байткод у классов/функций которые написаны в "новом стиле" чуть ли не в 2 раза длиннее. Но, так как создание класса/функции у нас происходит один раз, не то что бы это как-то влияло на общую картину(я думаю, что в кодогенерации, результат которой исполняется на лету, никто не использует тайпхинты)
А
type как soft-keyword просто замена TypeAlias. Не считаю это тем изменением которое было необходимо.- 👍 3
Post #5
2.39K
3.12 valid syntax
type Alias[T: ([T for T in (T, [1])[1]], T)] = [T for T in T.__name__]- 🤯 9
- 🔥 1
Channel created