PyPy 1.7

> Речь не об этом, ты выхватил моё сообщение из контекста. Речь о том что питон не знает в каком порядке вызывать деструкторы, а не о том что он не может найти циклические ссылки.

А должно иметь значение, в каком порядке вызывать деструкторы?

А должно иметь значение, в каком порядке вызывать деструкторы?

Конечно имеет. Высвобождение памяти объекта подразумевает что объект нигде больше не используется. А теперь представь что у тебя циклическая ссылка и инстансы в __del__, скажем, удаляют ссылки друг на друга. Как тогда поступать питону?

Вообще, у меня есть парочка решение, но оно кривое. Надо что бы после смерти объекта все указатели на него оставались валидными. Можно, например, объект подменять какой-нить пустышкой по тому же адресу.

А должно иметь значение, в каком порядке вызывать деструкторы?

Ну, вообще-то говоря, если под деструкторами понимать деинициализаторы - то, естественно имеет. Могу, если это требуется привести пример, но, вообще-то, я дольше буду по клавиатуре стучать, чем Вы придумыете его самостоятельно.

Но. Вообще, в питоне деинициализаторы крайне редки (а в джаве, например, ещё и не гарантируется их выполнение, что автоматически приводит к декретному запрету на использование finalize()). Соответственно, чаще всего проблемы правильного порядка выполнения деинициализаторов не существует.

вечером выложу RPM для RHEL6

http://ompldr.org/vYmZ6NQ пока вот SRPM

> Ну, вообще-то говоря, если под деструкторами понимать деинициализаторы - то, естественно имеет. Могу, если это требуется привести пример, но, вообще-то, я дольше буду по клавиатуре стучать, чем Вы придумыете его самостоятельно.

Если деструктор будет заниматься только освобождением ресурсов текущего объекта, то нет никакой необходимости соблюдать порядок даже при циклических ссылках. например есть 2 объекта с ссылками друг на друга. вызываем деструктор первого, он закрывает сокеты, пишет в лог и все такое. вместе с этим у него пропадает ссылка на второй объект. Поскольку на второй объект больше ничего не ссылается - он также уничтожается. Можно и в обратном порядке, никакой разницы.

Конечно если в одном объекте вызывать дестрой другого, то будет месиво.

В питоне основная проблема в том, что он не может выделить эти самые «островки», которые не связаны с основной программой.

http://ompldr.org/vYmczMw ну и вот сопсно то, что собралось.

Именно поэтому я явно разделил деструктор и финализатор. В языках с автоматическим управлением памятью программисту доступны только последние.

Циклические зависимости для финализатора - это катастрофа. Причём, катастрофа именно на логическом уровне, а не уровне реализации в конкретном языке. Представьте себе, что финализатор объекта 1 обращается в ходе финализации к объекту 2 и ждёт от него какого-то вменяемого поведения. А финализатор объекта 2 - к объекту 1. При этом сама природа финализации предполагает, что после завершения финализации объекты находятся в неработоспособном состоянии, и их больше уже не дёрнут.

Налицо логическое противоречие, которое можно разрешить двумя способами, во многом декретными:

1. объявить, что финализация не гарантирована средой. Следующим шагом будет административный запрет на использование какой-либо логики в финализаторах и, дальше, полный отказ от них.

2. предположить, что программисты будут достаточно аккуратны и не будут лепить циклические ссылки + нетривиальные финализаторы. По отдельности - можно, вместе - чревато.

Не понимаю зачем вообще может понадобится в финализаторе или деструкторе помещать какую либо логику, а тем более завязываться на другие объекты? в финализаторе этого объекта должны производиться сопровождающие очистку действия ЭТОГО объекта. Другой объект сам разберётся, как его почиститься.

Финализаторы в языках со сборщиками мусора по сути не нужны, так как время их срабатывания не детерминировано. Именно поэтому появились такие штуки как using в C# и with в Python.

> только один поток операционной системы

Это не проблема Питон. Отдельные процессы рулят.

>Проблема питона в том, что в каждый момент времени исполняется только один поток операционной системы, на котором работает интерпретатор.

Это не проблема. Потоки могут использоваться не только для того чтобы быстрее считать. Например нужно сделать интерфейс неблокирующим — как тут может помешать GIL, я не представляю. А жаловаться на то, что распараллеливание не дает прироста производительности глупо — питон тормоз by-design, и не предназначен для вычислительных задач.

> питон тормоз by-design, и не предназначен для вычислительных задач.

А как же numpy? mpi4py?

>mpi4py

Судя по названию, это для взаимодействия процессов, а не потоков.

numpy

Это нативные биндинги. Вопрос к питонистам: когда поток входит в нативную функцию, снимается ли блокировка GIL?

>Вопрос к питонистам: когда поток входит в нативную функцию, снимается ли блокировка GIL?

Проверил сам: да, снимается.

Сделал два потока, каждый из них запускает нативную вычислительную функцию. Программа съедает 200% процессора, т.е. потоки выполняются одновременно.