История изменений

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

У питона библиотеки — это питоньи модули, они же — питоньи объекты. А питоньи объекты — подсчет ссылок со сборкой мусора. Сборщик мусора каждый раз дергает счетчик туда-сюда, чтобы обнаружить кольца. Есть питоны с трассировочным сборщиком, но проблема в том, что питон следует парадигме «реализация является спецификацией», и потому есть код, который завязан на подсчет ссылок и высвобождение сразу по выходу переменной из видимости — этот код сломается, если отложить высвобождение объекта на потом (потому интерпретаторы на трассирующих GC не сыскали славы). Там много еще веселья, вроде метода __del__, который вообще не умеет в циклические ссылки и при обнаружении взаимных ссылок у объектов с методами __del__ сборщик мусора выдает ошибку и утекает ресурсами.

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

У питона библиотеки — это питоньи модули, они же — питоньи объекты. А питоньи объекты — подсчет ссылок со сборкой мусора. Сборщик мусора каждый раз дергает счетчик туда-сюда, чтобы обнаружить кольца. Есть питоны с трассировочным сборщиком, но проблема в том, что питон следует парадигме «реализация является спецификацией», и потому есть код, который завязан на подсчет ссылок и высвобождение сразу по выходу переменной из видимости — этот код сломается, если отложить высвобождение объекта на потом. Там много еще веселья, вроде метода __del__, который вообще не умеет в циклические ссылки и при обнаружении взаимных ссылок у объектов с методами __del__ сборщик мусора выдает ошибку и утекает ресурсами.