Які недоліки Stackless Python? [зачинено]


127

Я нещодавно читав про Stackless Python, і, схоже, він має багато переваг порівняно з ванільним cPython. Він має всі ці цікаві функції, як нескінченна рекурсія, мікропотоки, продовження тощо, і в той же час швидший, ніж cPython (близько 10%, якщо вірити вікі Python ) і сумісний з ним (принаймні версії 2.5, 2.6 та 3,0).

Все це виглядає майже занадто добре, щоб бути правдою. Однак, TANSTAAFL , я не бачу великого ентузіазму до безлічі серед спільноти Python, і PEP 219 так і не втілився в життя. Чому так? Які недоліки безрецептурних? Які скелети ховаються у шафі без столу?

(Я знаю, що Stackless не пропонує реальної одночасності, просто простіший спосіб програмування одночасно. Це насправді не турбує мене.)

Відповіді:


165

Я не знаю, звідки у "Вікі" з'явився той "Бездоглядний на 10% швидше", але знову ж таки я ніколи не намагався вимірювати ці показники. Я не можу думати про те, що робить безрезультатний, щоб змінити таку велику різницю.

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

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

З цієї причини початкова документація була поганою. Було кілька описів того, як його використовувати, з найкращими сторонніми учасниками. На PyCon 2007 я виступив з доповіддю " Використання бездоганних ", яка пройшла непогано, згідно номерів опитування PyCon. Річард Тью зробив чудову роботу, збираючи ці дані, оновлюючи stackless.com та підтримуючи розповсюдження, коли з’являються нові випуски Python. Він працівник CCP Games , розробник EVE Online, який використовує Stackless як важливу частину їхньої ігрової системи.

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

Ще однією складністю був вихідний код. У своєму первісному вигляді він потребував змін у багатьох частинах Python, що зробило Guido van Rossum, керівника Python, настороженим. Частиною причини, я думаю, була підтримка call / cc, яку згодом було видалено як "надто схожу на підтримку goto, коли є кращі форми вищого рівня". Я не впевнений у цій історії, тому просто прочитайте цей параграф як "Безрезультатний, щоб вимагати занадто багато змін".

Пізніші випуски не потребували змін, і Tismer продовжував наполягати на включенні її в Python. Хоча було певне врахування, офіційна позиція (наскільки я знаю) полягає в тому, що CPython - це не лише реалізація Python, але й призначена як опорна реалізація, і вона не буде включати функцію Stackless, оскільки вона не може бути реалізована Jython або Залізний пітон.

Не існує абсолютно ніяких планів на " значні зміни в кодовій базі ". Ця цитата та посилання гіперпосилання з Arafangion's (див. Коментар) походять приблизно з 2000/2001. Структурні зміни давно зроблені, і це те, що я згадував вище. Нестабільний, як зараз, стабільний і зрілий, за останні кілька років лише незначні зміни до кодової бази.

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

Хоча, якщо ви хочете тренуватися в безлічі, не соромтесь зв’язатися зі мною ! :)


39

щоб знайти цю дискусію, пройшло досить багато часу. У той час я не був на PyPy, але мав 2-річну справу з психікою, поки здоров'я не зупинило це все досить різко. Зараз я знову активний і розробляю альтернативний підхід - презентую його на EuroPython 2012.

Більшість тверджень Ендрюса є правильними. Деякі незначні доповнення:

Stackless був значно швидшим, ніж CPython, 10 років тому, тому що я оптимізував цикл перекладача. У той час Гвідо не був готовий до цього. Через кілька років люди зробили подібні оптимізації, а ще більші та кращі, що робить бездоганний трохи повільніше, як і очікувалося.

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

Аргументи на кшталт "інші реалізації не можуть цього зробити" відчували мене завжди кульгавими, оскільки є й інші приклади, коли цей аргумент також може бути використаний. Я думав, що краще забути про це і залишитись у добрій дружбі з Гвідо, маючи власний дистрибутив.

Тим часом все знову змінюється. Я працюю над PyPy та Stackless як розширення. Про це поговоримо іноді пізніше

Ура - Кріс


5

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


1
Джерело? Мені це цікаво, але я, очевидно, не можу повірити тобі лише тому, що ти так сказав. Я б виглядав дурнем, якби ти помилявся, і я почав говорити про те, як це було цікаво.
Девін Жанп'єр

2
Відмінний момент. Вибачте, я не маю посилання, тому що це було в irc розмові в #python на freenode, проте мені вдалося знайти стародавню розмову зі списку розсилки на gnosis.cx/download/charming_python_10_outtakes.html, яка дає багато більше розуміння ситуація.
Арафангіон

Це посилання дійсно чудове. Це відповідає на багато моїх запитань.
Ryszard Szopa

Цій посилання віком 8 або 9 років (вона говорить про Python 2.1), і будь-які дискусії щодо майбутніх змін до бази коду давно не відбулися. Безрезультатний Python стабільний і зрілий, і немає планів на "значні зміни в кодовій базі".
Ендрю Далке

Далке: Так і відбувається - якщо відбулися суттєві зміни в будь-яких рішеннях щодо інтеграції змін, сміливо придумай нову посилання, однак я підозрюю, що це давнє джерело, яке я надав, просто почало тенденцію мати окремі варіанти python, наприклад, JPython, IronPytion ..
Arafangion

3

Мені також цікаві відповіді тут. Я трохи пограв із Stackless і, схоже, це було б гарним надійним доповненням до стандартного Python.

PEP 219 згадує потенційні труднощі з викликом коду Python із коду С, якщо Python хоче змінити інший стек. Потрібно було б знайти способи їх виявлення та запобігання (щоб уникнути пошкодження стека C). Я думаю, що це можна відстежити, тому мені також цікаво, чому безрезультатний повинен стояти самостійно.


3
PEP 219 виповнилося 9 років і серйозно застаріло. Труднощі "виклику коду Python з коду С" є лише в реалізації, обговореній в PEP, і не в Stackless. Назва PEP ("Stackless Python") є дещо помилковим; вона черпала своє натхнення у "Безрезультатного", і все.
Ендрю Далке
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.