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

Недавно я читал о Stackless Python, и, похоже, он имеет много преимуществ по сравнению с ванильным cPython. Он имеет все эти классные функции, такие как бесконечная рекурсия, микропотоки, продолжения и т. Д., И в то же время он быстрее, чем cPython (около 10%, если верить вики Python ) и совместим с ним (по крайней мере версии 2.5, 2.6. и 3,0).

Все это выглядит слишком хорошо, чтобы быть правдой. Однако, TANSTAAFL , я не вижу большого энтузиазма по поводу Stackless среди сообщества Python, а PEP 219 так и не был реализован. Это почему? Какие недостатки у Stackless? Какие скелеты спрятаны в шкафу Stackless?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ура - Крис

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

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

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