Комментарии 9
other.clear() уменьшает ob_refcnt в 0
Зачем в питоновых объектах вообще рефкаунт? Он же не способен справляться с циклами и в любом случае рядом живёт полноценный сборщик мусора.
Ответ тянет на полноценную статью :)
Просто нужно рассказать про:
Возможность отключать
gcob_refcntв 3.13 с free-threadingИсторию вопроса
Встраиваемые версии Python
Скорость работы
С удовольствием почитал бы такую статью.
Скорость работы
Без рефкаунта будет быстрее, его не надо будет на каждый чих инкрементить/декрементить. Ну и существует куча других языков со сборщиками мусора существенно быстрее питона.
Встраиваемые версии Python
Насколько я понимаю, какой-нибудь micropython со взрослым питоном имеет довольно мало чего общего в плане реализации. Или вы про что-то другое?
Историю вопроса
Вот в то что рефкаунт остался как легаси-атавизм готов поверить.
Как легаси поведение тоже.
Типичный код вида
print("ahaha", file=open("dst.txt", "w"))
ohoho = open("dst.txt").read()с рефкаунтом объекты финализируются сразу после использования.
Без рефкаунта это произойдёт в непредсказуемый момент времени сильно позже.
Разумеется, безопасно писать
with open("dst.txt", "w") as f:
print("ahaha", file=f)
with open("dst.txt") as f:
ohoho = f.read()но это более громоздко.
И опять же, существует легаси код и легаси стиль, с которым надо что-то делать, а не радикально ломать обратную совместимость.
Ну между вторым и третьим питоном настолько всё сломались, что это кажется были бы мелочи.
Видимо, мейнтейнеры питона, включая пожизненного диктатора, побоялись устраивать второе ледовое побоище, им 2to3 хватило.
Ну а что касается скорости, то инкременты-декременты на каждый чих не выглядят большими затратами по сравнению с бизнес-логикой, а уборка мусора и так и этак сожрёт положенное ей время, будь то детерминизм на рефкаунтах или какие-либо отложенные сценарии. Единственный по-настоящему дешёвый сборщик мусора - это убийство процесса.
Крутое расследование!
В целом, класс проблем "весь мир внезапно поменялся" не уникален для Python или меж-языковых биндингов. Например, в Qt сигналы могут соединяться с абсолютно любыми слотами, и после диспатча сигнала может произойти что угодно — вплоть до завершения программы. В особо критичных местах голые указатели оборачиваются в QPointer (типа weak pointer), даже this, потому что, скажем, щелчок по меню или кнопке диалога часто приводит к закрытию окна и удалению дерева виджетов. Также, похожая ситуация и с корутинами: никогда не знаешь, что произойдет во время паузы в yield, тоже необходимо всё оборачивать и перепроверять.
Проблемы вызова Python кода из C кода