Какие недостатки у Stackless Python?
Я недавно читал о Stackless Python, и он, кажется, имеет много преимуществ по сравнению с vanilla cPython. Он имеет все эти интересные функции, как бесконечная рекурсия, микропотоки, продолжения и т. Д., И в то же время он быстрее, чем cPython (около 10%, если верить Python-вики), и совместим с ним (по крайней мере, версии 2.5, 2.6). и 3,0).
Все это выглядит слишком хорошо, чтобы быть правдой. Тем не менее, TANSTAAFL, я не вижу особого энтузиазма по поводу Stackless среди сообщества Python, и PEP 219 так и не был реализован. Это почему? Какие недостатки у Stackless? Какие скелеты спрятаны в шкафу Stackless?
(Я знаю, что Stackless не предлагает настоящий параллелизм, просто более простой способ программирования параллельным способом. Это меня не беспокоит.)
4 ответа
Я не знаю, откуда взялся этот "Stackless на 10% быстрее" в вики, но опять же я никогда не пытался измерить эти показатели производительности. Я не могу думать о том, что Stackless делает, чтобы иметь значение настолько большое.
Stackless - удивительный инструмент с несколькими организационными / политическими проблемами.
Первое происходит из истории. Кристиан Тисмер заговорил о том, что в итоге стало Stackless около 10 лет назад. У него было представление о том, что он хотел, но ему было трудно объяснить, что он делает и почему люди должны это использовать. Отчасти это связано с тем, что в его прошлом не было обучения CS по таким идеям, как сопрограммы, а также потому, что его презентации и дискуссии очень ориентированы на реализацию, что трудно для любого, кто еще не углубился в продолжение, понять, как использовать его в качестве решения для их проблемы.
По этой причине исходная документация была плохой. Было несколько описаний того, как его использовать, с лучшими сторонними авторами. На PyCon 2007 я выступил с докладом " Использование Stackless", который прошел довольно хорошо, согласно данным опроса PyCon. Ричард Тью проделал огромную работу, собирая их, обновляя http://stackless.com/ и поддерживая дистрибутив, когда появляются новые версии Python. Он сотрудник CCP Games, разработчика EVE Online, которая использует Stackless как неотъемлемую часть своей игровой системы.
Игры CCP - это также самый большой пример из реальной жизни, который люди используют, когда говорят о Stackless. Основным учебным пособием для Stackless является " Введение в параллельное программирование с использованием Stackless Python" Гранта Олсона, которое также ориентировано на игры. Я думаю, что это дает людям искаженное представление о том, что Stackless ориентирован на игры, когда игры более ориентированы на продолжение.
Еще одной трудностью был исходный код. В своем первоначальном виде это потребовало изменений во многих частях Python, что сделало Guido van Rossum, лидера Python, настороженным. Я думаю, что одной из причин была поддержка call / cc, которая позже была удалена как "слишком похожая на поддержку goto, когда есть более качественные формы более высокого уровня". Я не уверен насчет этой истории, поэтому просто прочитайте этот абзац как "Stackless раньше требовал слишком много изменений".
Более поздние выпуски не требовали изменений, и Тисмер продолжал настаивать на его включении в Python. Несмотря на некоторые соображения, официальная позиция (насколько мне известно) состоит в том, что CPython - это не только реализация Python, но и эталонная реализация, и он не будет включать в себя функциональность Stackless, поскольку он не может быть реализован Jython. или железный питон.
Нет абсолютно никаких планов относительно "значительных изменений в кодовой базе". Эта цитата и ссылка на гиперссылку Арафангиона (см. Комментарий) относятся примерно к 2000/2001. Структурные изменения уже давно сделаны, и это то, что я упомянул выше. Безупречный, как сейчас, стабильный и зрелый, с небольшими изменениями в кодовой базе за последние несколько лет.
Одно последнее ограничение для Stackless - нет сильного сторонника Stackless. В настоящее время Тисмер тесно связан с PyPy, который является реализацией Python для Python. Он реализовал функциональность Stackless в PyPy и считает, что он намного превосходит сам Stackless, и считает, что PyPy - это путь в будущее. Тью поддерживает Stackless, но он не заинтересован в адвокации. Я думал о том, чтобы быть в этой роли, но не мог понять, как я мог получить доход от этого.
Хотя, если вы хотите тренироваться в Stackless, не стесняйтесь обращаться ко мне!:)
Это заняло довольно много времени, чтобы найти это обсуждение. В то время я не был на PyPy, но у меня был двухлетний роман с психом, пока здоровье не остановило все это довольно резко. Сейчас я снова активен и разрабатываю альтернативный подход - представлю его на EuroPython 2012.
Большинство утверждений Эндрюса верны. Некоторые незначительные дополнения:
10 лет назад Stackless был значительно быстрее CPython, потому что я оптимизировал цикл интерпретатора. В то время Гвидо не был к этому готов. Несколько лет спустя люди сделали похожие оптимизации и даже больше и лучше, что делает Stackless немного медленнее, чем ожидалось.
О включении: ну, в начале я был очень настойчив и убежден, что Stackless - это путь. Позже, когда это было почти возможно, я потерял к этому интерес и предпочел оставить все как есть, частично из-за разочарования, частично чтобы сохранить контроль над Stackless.
Аргументы типа "другие реализации не могут этого сделать" всегда казались мне неубедительными, поскольку есть и другие примеры, где этот аргумент также можно использовать. Я подумал, что лучше об этом забыть и остаться в хорошей дружбе с Гвидо, имея свой собственный дистрибутив.
Тем временем все снова меняется. Я работаю над PyPy и Stackless в качестве расширения. Об этом я расскажу позже.
Ура - Крис
Если я правильно помню, Stackless планировалось включить в официальный CPython, но автор стека сказал, что ребята из CPython этого не делают, потому что он планирует внести некоторые существенные изменения в базу кода - предположительно, он хотел, чтобы интеграция была сделана позже, когда проект был более зрелым.
Я также заинтересован в ответах здесь. Я немного поиграл со Stackless, и похоже, что это было бы хорошим дополнением к стандартному Python.
PEP 219 упоминает о потенциальных трудностях вызова кода Python из кода C, если Python хочет перейти на другой стек. Должны быть способы обнаружения и предотвращения этого (чтобы избежать разрушения стека C). Я думаю, что это поддается, хотя мне также интересно, почему Stackless должен стоять сам по себе.