Каковы недостатки Stackless Python?[закрыто]

Question

Недавно я читал о Бесстекленный Python и, похоже, у него есть много преимуществ по сравнению с ванильным CPython.В нем есть все эти замечательные функции, такие как бесконечная рекурсия, микропотоки, продолжения и т.д.и в то же время быстрее, чем CPython (около 10%, если вики - сайт Python в это нужно верить) и совместим с ним (по крайней мере, версий 2.5, 2.6 и 3.0).

Все это выглядит слишком хорошо, чтобы быть правдой.Однако, ТАНСТАФЛЬ, Я не вижу особого энтузиазма по поводу Stackless среди сообщества Python, и БОДРОСТЬ ДУХА 219 никогда не приходил к осознанию.Почему это так?Каковы недостатки Stackless?Какие скелеты спрятаны в шкафу Стэклесса?

(Я знаю, что Stackless не предлагает реального параллелизма, просто более простой способ программирования параллельным способом.На самом деле меня это не беспокоит.)

Answer 1

Я не знаю, откуда взялось выражение "Stackless работает на 10% быстрее" в Wiki, но опять же, я никогда не пытался измерить эти показатели производительности.Я не могу придумать, что делает Stackless, чтобы так сильно изменить ситуацию.

Stackless - удивительный инструмент с несколькими организационными / политическими проблемами.

Первое взято из истории.Кристиан Тисмер начал рассказывать о том, что в конечном итоге стало Stackless около 10 лет назад.У него было представление о том, чего он хочет, но ему было трудно объяснить, что он делает и почему люди должны этим пользоваться.Отчасти это связано с тем, что в его прошлом не было подготовки по CS в отношении таких идей, как сопрограммы, и потому, что его презентации и обсуждения очень ориентированы на реализацию, что трудно для тех, кто еще не разбирается в продолжениях, понять, как использовать это в качестве решения своих проблем.

По этой причине первоначальная документация была некачественной.Там было несколько описаний того, как им пользоваться, с лучшими из сторонних авторов.На PyCon 2007 я выступил с докладом на тему "Использование Stackless" который прошел довольно хорошо, согласно данным опроса PyCon.Ричард Тью проделал огромную работу, собирая их, обновляя stackless.com, и поддержание дистрибутива при появлении новых версий Python.Он сотрудник Игры КПК, разработчики EVE Online, которая использует Stackless в качестве неотъемлемой части своей игровой системы.

CCP games также является самым большим примером из реального мира, который люди используют, когда говорят о Stackless.Основным учебным пособием по Stackless является книга Гранта Олсона "Введение в параллельное программирование с помощью Stackless Python", который также ориентирован на игру.Я думаю, это дает людям искаженное представление о том, что Stackless ориентирован на игры, в то время как игры легче ориентировать на продолжение.

Еще одной трудностью был исходный код.В своем первоначальном виде он требовал изменений во многих частях Python, что заставило Гвидо ван Россума, руководителя Python, насторожиться.Одной из причин, я думаю, была поддержка call / cc, которая позже была удалена как "слишком похожая на поддержку goto, когда есть лучшие формы более высокого уровня". Я не уверен в этой истории, поэтому просто прочтите этот абзац как "Раньше Stackless требовал слишком большого количества изменений".

Более поздние версии не требовали внесения изменений, и Тисмер продолжал настаивать на его включении в Python.Хотя были некоторые соображения, официальная позиция (насколько я знаю) заключается в том, что CPython - это не только реализация Python, но и эталонная реализация, и она не будет включать функциональность без стека, потому что она не может быть реализована Jython или Iron Python.

Нет абсолютно никаких планов на "существенные изменения в кодовой базе".Эта цитата и ссылочная гиперссылка из книги Арафангиона (см. Комментарий) относятся примерно к 2000/2001 году.Структурные изменения уже давно были сделаны, и это то, о чем я упоминал выше.Stackless в нынешнем виде является стабильным и зрелым, с незначительными изменениями в кодовой базе за последние несколько лет.

Последнее ограничение, связанное со Stackless - нет решительных сторонников Stackless.Тисмер в настоящее время глубоко вовлечен в ПыПи, который является реализацией Python для Python.Он реализовал функциональность Stackless в PyPy и считает, что она намного превосходит саму Stackless, и считает, что PyPy - это путь в будущее.Тью поддерживает Stackless, но он не заинтересован в адвокации.Я подумывал о том, чтобы занять эту должность, но не мог понять, как я мог бы получать от этого доход.

Хотя, если вы хотите потренироваться в Stackless, не стесняйтесь свяжитесь со мной! :)

Answer 2

потребовалось довольно много времени, чтобы найти это обсуждение.За что времени я не был на Python. но было дело 2-х лет с психо, пока здоровье прекратил все это довольно резко.Сейчас я снова активен и разрабатываю альтернативный подход - представлю его на EuroPython 2012.

Большинство утверждений Эндрюса верны.Некоторые незначительные дополнения:

10 лет назад Stackless был значительно быстрее CPython, потому что я оптимизировал цикл интерпретатора.В то время Гвидо не был готов к этому.Несколько лет спустя люди провели аналогичную оптимизацию и даже больше и лучше, что сделало Stackless немного медленнее, как и ожидалось.

О включении:ну, поначалу я был очень настойчив и убежден, что Stackless - это правильный путь.Позже, когда было почти возможно подключиться, я потерял к этому интерес и предпочел оставить все как есть, частично из-за разочарования, частично для того, чтобы сохранить контроль над Stackless.

Аргументы типа "другие реализации не могут этого сделать" всегда казались мне неубедительными, поскольку есть другие примеры, где этот аргумент также можно было бы использовать.Я подумал, что мне лучше забыть об этом и оставаться в хорошей дружбе с Гвидо, имея свой собственный дистрибутив.

Тем временем ситуация снова меняется.Я работаю над PyPy и Stackless в качестве расширения, об этом я расскажу позже

Ваше здоровье, Крис

Answer 3

Если я правильно помню, Stackless планировалось включить в официальный CPython, но автор stackless сказал сотрудникам CPython не делать этого, потому что он планировал внести некоторые существенные изменения в кодовую базу - предположительно, он хотел, чтобы интеграция была выполнена позже, когда проект станет более зрелым.

Answer 4

Меня также интересуют ответы на эти вопросы.Я немного поиграл со Stackless, и, похоже, это было бы хорошим дополнением к стандартному Python.

В PEP 219 упоминаются потенциальные трудности с вызовом кода Python из кода C, если Python захочет перейти на другой стек.Должны быть способы обнаружить и предотвратить это (чтобы избежать разгрома стека C).Однако я думаю, что это выполнимо, поэтому мне также интересно, почему Stackless должен стоять сам по себе.