Каковы недостатки Stackless Python?

Ответ 1

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Приветствия - Крис

Ответ 3

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

Ответ 4

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

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