Nie wiem, skąd wziął się "Stackless jest o 10% szybszy" na Wiki, ale z drugiej strony nigdy nie próbowałem mierzyć tych liczb wydajności. Nie mogę myśleć o tym, co Stackless robi, żeby zrobić tak wielką różnicę.
Stackless to niesamowite narzędzie z kilkoma problemami organizacyjnymi/politycznymi.
Pierwsza pochodzi z historii. Christian Tismer zaczął mówić o tym, co ostatecznie stało się Stackless około 10 lat temu. Miał wyobrażenie o tym, czego chciał, ale trudno mu było wyjaśnić, co robi i dlaczego ludzie powinni go używać. Dzieje się tak częściowo dlatego, że jego wykształcenie nie miało przeszkolenia w zakresie CS w odniesieniu do pomysłów takich jak coroutines, a jego prezentacje i dyskusja są zorientowane na wdrażanie, co jest trudne dla każdego, kto nie jest jeszcze w głębi duszy, aby zrozumieć, jak używać go jako rozwiązania ich problemy.
Z tego powodu początkowa dokumentacja była słaba. Było kilka opisów tego, jak go używać, z najlepszymi z zewnętrznych dostawców. W PyCon 2007 wygłosiłem wykład na temat "Using Stackless", który sprawdził się całkiem dobrze, według danych z ankiety PyCon. Richard Tew wykonał świetną robotę zbierając je, aktualizując stackless.com i utrzymując dystrybucję po pojawieniu się nowych wersji Pythona. Jest pracownikiem firmy CCP Games, twórcy EVE Online, który wykorzystuje Stackless jako istotną część swojego systemu gier.
Gry CCP to także największy przykład, który ludzie używają, gdy mówią o Stackless. Główny tutorial dla Stackless to "Introduction to Concurrent Programming with Stackless Python" Granta Olsona, który jest również zorientowany na grę. Wydaje mi się, że daje to ludziom wypaczony pomysł, że Stackless jest zorientowany na gry, kiedy bardziej jest to, że gry są łatwiejsze do kontynuacji.
Kolejną trudnością jest kod źródłowy.W swojej pierwotnej formie wymagał zmian w wielu częściach Pythona, co sprawiło, że Guido van Rossum, prowadzący Python, był ostrożny. Jednym z powodów, moim zdaniem, było wsparcie dla call/cc, które zostało później usunięte jako "zbyt podobne do wspierania goto, gdy istnieją lepsze formy wyższego poziomu". Nie mam pewności co do tej historii, więc po prostu przeczytaj ten akapit jako "Stackless, który wymagał zbyt wielu zmian".
Późniejsze wydania nie wymagały zmian, a Tismer nadal naciskał na włączenie go do Pythona. Podczas gdy było pewne rozważanie, oficjalne stanowisko (o ile mi wiadomo) jest takie, że CPython jest nie tylko implementacją Pythona, ale ma służyć jako implementacja referencyjna i nie będzie zawierał funkcji Stackless, ponieważ nie może być zaimplementowana przez Jython lub Żelazny Python.
Nie ma absolutnie żadnych planów dotyczących "istotnych zmian w bazie kodu". Ten cytat i odnośnik do hiperłącza z Arafangiona (patrz komentarz) pochodzą z grubsza 2000/2001. Zmiany strukturalne już dawno zostały zrobione i to właśnie wspomniałem powyżej. Bezkształtne jak teraz jest stabilne i dojrzałe, z niewielkimi zmianami w kodzie źródłowym w ciągu ostatnich kilku lat.
Jedno ostateczne ograniczenie z Stackless - nie ma silnego adwokata dla Stackless. Tismer jest teraz głęboko zaangażowany w PyPy, która jest implementacją Pythona dla Pythona. Zaimplementował funkcję Stackless w PyPy i uważa ją za znacznie lepszą od Stackless i uważa, że PyPy jest drogą przyszłości. Tew utrzymuje Stackless, ale nie jest zainteresowany rzecznictwem. Rozważałem bycie w tej roli, ale nie mogłem zobaczyć, w jaki sposób mogę zarabiać na tym.
Chociaż, jeśli chcesz trenować w Stackless, zapraszam do contact me! :)
PEP 219 ma 9 lat i poważnie nieaktualne. Trudności "wywoływania kodu Pythona z kodu C" są tylko w implementacji omawianej w PEP i nie są w Stackless. Nazwa PEP ("Stackless Python") jest trochę myląca; czerpał inspirację z Stackless i to wszystko. –