Вы задаете правильный вопрос - зачем. Самый простой ответ выполнить очистку/удаление/финализацию (называйте как хотите) объекта. Т.к. бессмертные объекты сейчас в основном внутренние системные объекты, то мы можем знать когда на эти объекты не осталось ссылок. В этом случае мы можем выполнить `_Py_SetMortal(op, 1)` и после этого `Py_DECREF(op)` чтобы очистить объект. Понятно, что это не относится к accidentally immortal объектам - они у нас просто утекут в данный момент. Думаю что PEP 797 в каком-то виде ответит на эти вопросы, стоит немного подождать.
Проблема в том, что Py_INCREF/Py_DECREF как рак пронизывают не только весь CPython, но и все C-расширения - т.е. отказ от подсчета ссылок это слом обратной совместимости, боюсь что даже 4.0 на такое не пойдет. Так что ваше предложение потребует переписать весь CPython. Не спорю, это было бы интересно, но кто будет платить за банкет, не понятно.
Потом, как показывает практика, на sys.getrefcount ссылаются в программах.
Подсчета ссылок нет в PyPy, например. Не смотря на то что это Python, это все таки в меньшей степени Python.
Если посмотрите интервью с Эриком о появлении субинтерпретаторов, то он как раз и говорит, что идея нескольких интерпретаторов появилась еще в середине 90, и как раз под влиянием Tcl/Tk, но была реализована только в C-API и то кое-как.
А сделать это "продакшен-реди" и доступным из Python - а) было никому не надо, б) не было никого кто это мог бы сделать.
Питон в основном развивается энтузиастами и тот же Эрик начал работать над этой темой чуть ли не 10 лет назад и в свое свободное время. И чтобы это сделать пришлось изменить очень многое из того что там наросло годами.
Поэтому это не вопрос "додумался" (понятно что мы все умнее всех остальных), это вопрос того что кто-то это взял и сделал.
Какой-то особой магии относительно системных ресурсов сейчас нет. Вы, грубо говоря, можете рассматривать приложение с субинтерпретаторами как обычное многопоточное приложение.
Хорошее замечание, спасибо - вылетело вчера из головы. Эрик в интервью у Никиты (https://t.me/opensource_findings/919) рассказывал, что в этом случае вам придется озаботиться вопросом синхронизации самостоятельно. И в этом смысле решения в free-threading и использование memoryview в качестве канала обмена информацией имеют много схожего.
как минимум общая область видимости/память, без необходимости сериализации данных между потоками
Это как плюс так и минус - теперь вы в коде на питоне обязаны синхронизировать доступ к вашим данным - уточню, что ft-build даст вам структуры данных, которые не ломаются при конкурентном доступе, но все проблемы многопоточности теперь ложаться на ваши плечи.
В случае субинтерпретаторов - у вас практически нет разделяемого состояния, вам не надо решать проблемы с защитой ваших состояний, проблемы гонки данных и взаимных блокировок. Надо порешать проблемы с эффективной передачей данных через общую очередь - но это гораздо меньшая поверхность проблем.
Вы задаете правильный вопрос - зачем. Самый простой ответ выполнить очистку/удаление/финализацию (называйте как хотите) объекта. Т.к. бессмертные объекты сейчас в основном внутренние системные объекты, то мы можем знать когда на эти объекты не осталось ссылок. В этом случае мы можем выполнить `_Py_SetMortal(op, 1)` и после этого `Py_DECREF(op)` чтобы очистить объект. Понятно, что это не относится к accidentally immortal объектам - они у нас просто утекут в данный момент. Думаю что PEP 797 в каком-то виде ответит на эти вопросы, стоит немного подождать.
Скорей всего вы хотели ответить в моей статье про бессмертные объектоы, но почему-то написали здесь. Предлагаю продолжить там, если что.
Мне не понятно, что вы имеете в виду под "runtime-валидатор" - предлагаю вам раскрыть свой вопрос там.
Проблема в том, что
Py_INCREF/Py_DECREFкак рак пронизывают не только весь CPython, но и все C-расширения - т.е. отказ от подсчета ссылок это слом обратной совместимости, боюсь что даже 4.0 на такое не пойдет. Так что ваше предложение потребует переписать весь CPython. Не спорю, это было бы интересно, но кто будет платить за банкет, не понятно.Потом, как показывает практика, на sys.getrefcount ссылаются в программах.
Подсчета ссылок нет в
PyPy, например. Не смотря на то что это Python, это все таки в меньшей степени Python.Как бы нормальный сборщик мусора с маркировкой а) работал бы в этом случае (см. причины появления) б) как бы он был обратно совместим?
Спасибо!
Спасибо! Будем стараться :)
Да, скорей всего так и есть.
Спасибо!
Спасибо!
Увы, но только у бессмертных объектов, которых по факту не так уж и много.
Если посмотрите интервью с Эриком о появлении субинтерпретаторов, то он как раз и говорит, что идея нескольких интерпретаторов появилась еще в середине 90, и как раз под влиянием Tcl/Tk, но была реализована только в C-API и то кое-как.
А сделать это "продакшен-реди" и доступным из Python - а) было никому не надо, б) не было никого кто это мог бы сделать.
Питон в основном развивается энтузиастами и тот же Эрик начал работать над этой темой чуть ли не 10 лет назад и в свое свободное время. И чтобы это сделать пришлось изменить очень многое из того что там наросло годами.
Поэтому это не вопрос "додумался" (понятно что мы все умнее всех остальных), это вопрос того что кто-то это взял и сделал.
Какой-то особой магии относительно системных ресурсов сейчас нет. Вы, грубо говоря, можете рассматривать приложение с субинтерпретаторами как обычное многопоточное приложение.
Хорошее замечание, спасибо - вылетело вчера из головы. Эрик в интервью у Никиты (https://t.me/opensource_findings/919) рассказывал, что в этом случае вам придется озаботиться вопросом синхронизации самостоятельно. И в этом смысле решения в free-threading и использование
memoryviewв качестве канала обмена информацией имеют много схожего.Это как плюс так и минус - теперь вы в коде на питоне обязаны синхронизировать доступ к вашим данным - уточню, что ft-build даст вам структуры данных, которые не ломаются при конкурентном доступе, но все проблемы многопоточности теперь ложаться на ваши плечи.
В случае субинтерпретаторов - у вас практически нет разделяемого состояния, вам не надо решать проблемы с защитой ваших состояний, проблемы гонки данных и взаимных блокировок. Надо порешать проблемы с эффективной передачей данных через общую очередь - но это гораздо меньшая поверхность проблем.
@Eclips4поздравляю!
А еще в некоторых версиях Python комбинацией
unraisablehookиaddaudithookможно свалить интерпретатор с SegFault :)Спасибо!
Ссылка на изменения лексера не работает.
Спасибо! Есть еще куда расти :)
Спасибо, взаимно! Кстати, мой первый реквест вы замержили :)
По поводу учебы и карьеры - пожелаю удачи, у вас хороший старт и впереди большие возможности.