Stackless python

28.10.2013 21:18 | Přečteno: 2368× | Obecné IT | | poslední úprava: 30.10.2013 01:06

Možná jste někdy měli na potřebu paralelizace vašeho pythonního scriptu a thready se pro vás ukázaly jako nevhodné z důvodu jejich vysoké náročnosti (zkuste si spustit 800 threadů a pochopíte o čem mluvím). Přesně pro takovéto případy byl vytvořen Stackless python, který vám umožní používat microthready/korutiny/tasklety za použití preemptivního multitaskingu.

Update

Na základě diskuze jsem se dozvěděl, že pythonní interpreter PyPy má v sobě podporu Stackless přímo zabudovanou. Pokud uvažujete o použití Stackless, tak tohle asi bude lepší cesta, než kompilace interpreteru.

Instalace

Instalaci jsem prováděl na Mintu 13, ale měla by být dost podobná na téměř všech debianovských systémech, kde již je nainstalován python 2.7. Postup je poměrně jednoduchý, ale je nutné kompilovat a upravit jeden konfigurák. Níže uvedené příkazy to automatizují tak, že je v podstatě jen stačí napastovat do konzole a občas zadat heslo na roota.

Návod je založený na článku Install Stackless Python on Ubuntu.

Příprava systému

sudo apt-get update
sudo apt-get install libreadline-dev
sudo apt-get build-dep python2.7

Stažení poslední verze stackless pythonu

cd /tmp
LAST_SL=`wget http://www.stackless.com/binaries/ -O - 2>/dev/null | grep export.tar.bz2 | grep -v md5 | cut -d '"' -f 8 | grep "stackless-2" | sort | tail -n 1`
wget "http://www.stackless.com/binaries/$LAST_SL"

tar -xvf $LAST_SL
rm $LAST_SL
LAST_SL=`echo $LAST_SL | cut -d "." -f 1`
cd $LAST_SL

Kompilace a instalace

./configure --prefix=/opt/stackless --enable-unicode=ucs4
make
sudo make install

Poinstalační fix

Doplnění symlinků na standardní pythonní moduly a úprava cest, kde má stackless hledat moduly. Úprava konfiguráku proběhne automaticky, použil jsem k tomu python, protože se mi nechtělo hrát si 7 hodin se sedem a jeho escape sekvencemi.

sudo ln -s /usr/lib/python2.7/dist-packages/ /opt/stackless/lib/python2.7/site-packages
sudo ln -s /usr/local/lib/python2.7/dist-packages/ /opt/stackless/lib/python2.7/dist-packages
sudo ln -s /opt/stackless/bin/python /usr/bin/stackless

cd /opt/stackless/lib/python2.7/
sudo python -c "a = '            sitepackages.append(os.path.join(prefix, \"lib\", \"site-python\"))'; print open('site.py').read().replace(a, '            sitepackages.append(os.path.join(prefix, \"lib\", \"python\" + sys.version[:3], \"dist-packages\"))\n'+a)" > /tmp/site_.py
sudo mv /tmp/site_.py site.py

Odstranění instalačního smetí

cd /tmp
rm -fr $LAST_SL

Test interpreteru

Interpreter se spouští příkazem stackless.

$ stackless
Python 2.7.5 Stackless 3.1b3 060516 (default, Oct 28 2013, 15:34:27) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import stackless
>>> 

Používání

Z programátorského hlediska probíhají interakce skrze modul stackless, který si ve Stackless interpreteru naimportujete. V klasickém pythonu vám importovat nepůjde, protože pro svůj běh vyžaduje úpravy interpreteru a způsobu, jakým jsou volány funkce (stackless = bez stacku).

Vytvoření taskletu

>>> import stackless
>>> def funkce(parametr):
... 	print parametr
... 
>>> t = stackless.tasklet(funkce)("prvni")
>>>

Co se vlastně ve výše uvedeném kódu stalo? Vytvořil jsem funkci nazvanou poeticky funkce, která přijímá jeden parametr, jenž je vypsán na stdout. Z této funkce jsem poté udělal takzvaný tasklet a předal mu textový parametr "první".

Tasklet byl automaticky přidán do interní fronty uvnitř modulu stackless. Reference na něj byla uložena do proměnné t.

Operace nad tasklety

Jak už jsem psal, jednotlivé tasklety jsou uchovávány ve frontě taskletů, Do této fronty mohou být přidávány pomocí .insert(), která tasklet přidá na konec fronty a také z ní mohou být odebírány pomocí .remove(). Pokud chcete přesunout konkrétní tasklet na začátek fronty a spustit ho, použijte .run(). Jestli potřebujete tasklet zabít, tak .kill().

Pro úplnost dodám, že tyto metody se volají přímo nad instancí konkrétního taskletu, tedy nad t z ukázky, nikoliv nad modulem stackless.

Ukázka

Pokud zavoláme nad konkrétním taskletem .run(), tak se přesune na vrchol fronty a provede:

>>> t.run()
prvni

Tasklet může proběhnout jen jednou, proto pokusíme-li se ho spustit znova, dostaneme chybu:

>>> t.run()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: You cannot run an unbound(dead) tasklet

Běh fronty taskletů

Výše uvedené ukázky nejsou moc platné a v podstatě neukazují nic, co by neuměl python sám o sobě. Nyní vám předvedu, jak spustit celou frontu taskletů:

#!/usr/bin/env stackless
# -*- coding: utf-8 -*-
import time
import stackless


def funkce(parametr):
	t1 = time.time()
	print "starting", parametr, t1
	
	for i in range(10000000):
		pass

	t2 = time.time()
	print "ending", parametr, t2, "-", t2 - t1


stackless.tasklet(funkce)("prvni")
stackless.tasklet(funkce)("druhy")
stackless.tasklet(funkce)("treti")


while stackless.getruncount() > 1:
	t = stackless.run(100)

	if t:
		t.insert()

funkce() tentokrát obsahuje výpis informací pro primitivní benchmark. Všimněte si foru, který iteruje skrz 10000000 položek. Použil jsem ho záměrně místo time.sleep(). Proč se dozvíte za okamžik.

while cyklus na konci scriptu obstarává veškerou práci - z fronty vyjme jeden tasklet, nechá ho proběhnout 100 python instrukcí a pokud mezi tím neskončil, tak ho vloží na konec fronty.

Z výše uvedeného odstavce plynou dvě věci:

1. Jedná se o preemptivní multitasking.
2. Multitasking se vztahuje na instrukce pythonního bytecode, ne na volání C API.

Nyní doufám chápete, proč jsem použil místo time.sleep() for smyčku - time.sleep() je callback na C API, což znamená, že se na něj multitasking nevztahuje. To je dobré mít na paměti.

Zatímco kooperativního multitaskingu lze do jisté míry dosáhnout i v obyčejném pythonu pomocí generátorů, preemptivní je možné dosáhnout pouze pomocí procesů, threadů, či Stackless pythonem, jehož tasklety jsou nejméně náročné na prostředky počítače.

Výstup

$ time stackless stackless.py 
starting prvni 1382985236.72
starting druhy 1382985237.26
starting treti 1382985237.8
ending druhy 1382985243.4 - 6.14155387878
ending prvni 1382985243.67 - 6.95054602623
ending treti 1382985243.92 - 6.12157416344

real	0m8.101s
user	0m6.888s
sys	0m1.136s

Pokud nechám funkci proběhnout třikrát lineárně za sebou, dostanu tyto hodnoty:

$ time stackless stackless.py 
starting první 1382985343.08
ending první 1382985345.28 - 2.19586610794
starting druhá 1382985345.28
ending druhá 1382985346.91 - 1.63068413734
starting třetí 1382985346.91
ending třetí 1382985348.51 - 1.59492611885

real	0m5.804s
user	0m5.036s
sys	0m0.568s

Paralelní běh tedy trval o 2.3s déle, než běh lineární. To je daň za přepínání taskletů a hlavně za jejich spuštění a ukončení, což je dle výpisu poměrně časově náročná činnost trvající desítky/stovky milisekund.

Rozdíl mezi kooperativním a preemptivním multitaskingem

Mladší ročníky, které si nepamatují doby DOSu a prvních Windows možná nebudou tušit, jaký je rozdíl mezi kooperativním a preemptivním multitaskingem.

Kooperativní multitasking je triviálnější. Spočívá v tom, že funkci (či procesu/programu) předáte řízení a doufáte, že vám ho někdy vrátí, aby jste mohli provést zase něco jiného. Po dobu běhu funkce nemáte nad systémem žádnou kontrolu a musíte doufat, že se funkce nedostane do stavu, kde se zasekne a celý systém zamrzne.

V kooperativním multitaskingu může běžet víc procesů zároveň, ale je na procesech, aby běžely jen zlomky času, po kterém vždy vrátí řízení systému, který mezi nimi přepne. Pokud se náhodou nějaký proces zdrží, tak všechny běžící procesy na chvíli zmrznou.

Preemptivní multitasking je chytřejší, i když náročnější na implementaci a na běh. Místo toho, aby procesu předal kompletní řízení mu předává řízení jen na nějaký okamžik. Může to být třeba na 1ms, nebo na 1000 instrukcí, to už záleží na konkrétní implementaci. Výhoda je v tom, že pokud se daný proces/fukce/program zasekne, tak neshodí celý systém a ostatní funkce/procesy/.. dále běží.

Kooperativní multitasking v pythonu

Pokud by někoho zajímalo, jak by vypadala výše uvedená ukázka přepsaná do čistého pythonu v kooperativním režimu pomocí generátorů:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import time

def funkce(parametr):
	t1 = time.time()
	print "starting", parametr, t1
	
	for i in range(10000000):
		if i % 100 == 0:
			yield

	t2 = time.time()
	print "ending", parametr, t2, "-", t2 - t1


fronta = [
	funkce("prvni"),
	funkce("druhy"),
	funkce("treti"),
]

while len(fronta) > 0:
	for f in fronta:
		try:
			f.next()
		except StopIteration:
			fronta.remove(f)

a zde je výstup:

$ time ./yield.py 
starting prvni 1382984400.16
starting druhy 1382984400.6
starting treti 1382984401.04
ending prvni 1382984412.9 - 12.7446539402
ending treti 1382984413.17 - 12.1312551498
ending druhy 1382984413.44 - 12.8393118382

real	0m14.347s
user	0m12.757s
sys	0m1.112s

Pokud dojde ve forsmyčce, kde je vyhazován yield k chybě (třeba nějaký cyklus, nebo špatně vyhodnocená podmínka), celý kód se zasekne a nepoběží ani jeden ze tří generátorů.

Zajímavé je, že kód běžel delší dobu, než v případě Stackless taskletů. Povšimněte si pořadí ukončení jednotlivých generátorů.

Pro úplnost dodám, že Stackless také umožňuje kooperativní multitasking, jen místo yield voláte stackless.schedule(). Jelikož python nabízí dost podobnou funkcionalitu v základu, nebudu se tím dále zabývat.

Komunikace

Jednotlivé tasklety spolu mohou komunikovat pomocí kanálů, což je vlastnost, kterou čisté pythonní generátory až do nedávna neměly a i v dnešní době to není tak přímočaré.

Kanál je možné vytvořit pomocí volání stackless.channel(). Data se odesílají přes volání ch.send() a přijímají přes ch.receive(). Dotaz na počet zpráv v kanálu je možné provést skrz property ch.balance (default 0).

Jak příjem, tak odesílání dat je blokující a zasekne celý tasklet. Nemá cenu to zkoušet v singleplayeru, pokud nemáte kód, který běží paralelně tak se to prostě zasekne a nic se neděje.

Zde je ukázka posílání dat mezi dvěma funkcemi:

#!/usr/bin/env stackless
# -*- coding: utf-8 -*-
import time
import stackless

def prvni(ch):
	ch.send("odesláno z první")

def druha(ch):
	print "druhá:", ch.receive()


ch = stackless.channel()

stackless.tasklet(prvni)(ch)
stackless.tasklet(druha)(ch)


while stackless.getruncount() > 1:
	t = stackless.run(100)

	if t:
		t.insert()

Odeslat je možné všechno možné, nemusí to být string, ale klidně pole, číslo atp..

Výstup

$ ./stackless.py 
druhá: odesláno z první

To je vše?

Téměř vše. Dokumentace se ještě zmiňuje o serializaci taskletů/kanálů, ale protože jsem to zatím neměl potřebu použít, tak jí zde nebudu rozmazávat - tenhle článek se brutálně zvrhl z osobních poznámek k instalaci, protože jsem zapomněl přestat psát. Berte ho tedy spíš jako takové představení Stackless v češtině, ne kompletní manuál.

Pokud vás Stackless zaujal, vřele doporučuji navštívit jeho domovskou stránku a přečíst si dokumentaci - jedná se jen o pár stránek.

Pokud by měl někdo potřebu většího tutoriálu, tak jeden drobně zastaralý (python 2.4) se dá najít zde: Introduction to Concurrent Programming with Stackless Python.

Kde Stackless používám

Stackless u mě našel využití v paralelním síťovém kódu, který prochází webem. Jednotlivé navázání spojení je totiž časově náročnější operace, než samotné stahování. Takhle se neustále načítají nové a nové tasklety s požadavky na webové stránky, takže program pořád něco dělá, místo aby vždy čekal 2 vteřiny na navázání spojení.

       

Komentáře

[Radek Miček]

Takhle se neustále načítají nové a nové tasklety s požadavky na webové stránky, takže program pořád něco dělá, místo aby vždy čekal 2 vteřiny na navázání spojení.

A to by nestačil CPython s nějakou knihovnou pro asynchronní zpracování?

[Bystroushaak]

V zásadě ano. Jenže ono by se to tak moc nelišilo a ve výsledku bych programoval skoro to samé, jen s tím rozdílem, že druhý kód by byl nepřehlednější a musel bych použít jiné knihovny, ne ty svoje oblíbené. Stackless je docela příjemná abstrakce pro programátora.

[sam]

Obavam se, ze ne GIL nelze obejit, musela by se prepsat vetsina kodu CPythonu.

Btw. pro takove pripady a nejen pro ne ocenuju genialni navrh Haskellu a vlastne i implementaci GHC. Nejen ze je trivialni paralelizovat, ale bezi to o rady rychleji.

[chrono]

Nebolo by dnes rozumnejšie používať greenlet (prípadne niečo, čo greenlet používa)?

[Bystroushaak]

Greenlet má jen kooperativní multitasking, pokud se nepletu.

[luky]

V cem je problem s 800 thready, GIL? Samotny Linux skaluje dobre a muzete si vytvorit desitky tisic threadu aniz by se to neja vyrazne projevilo v behu systemu.

[Bystroushaak]

Já jsem to ani moc nezkoumal, stačilo mi, že jsem musel provést hardreset jednou, poté co to sežralo všechny systémové prostředky tak dokonale, že pomohl až sysrq (jenže tam byla zábavná smyčka, která zase otevírala nové thready, takže proto hardreset).

[kralyk z abclinuxu]

Pokud si dobře vzpomínám, tak problém je v tom, že CPython nevytváří nativní (pthreads) thready, ale nějaké svoje vlastní a kód stejně běží v jednom threadu.

[Bystroushaak]

kód stejně běží v jednom threadu

Jo, tohle je jedna z bolestí pythonu.

[xkucf03]

Takže je pořád jediný způsob, jak využít vícejádrový procesor, spustit více interpretů Pythonu?

[Jakub Lucký]

reálně ano... Python k tomu má rozhraní jménem multiprocessing se stejným API jako thready...

Obecně se GIL považuje za největší problém CPythonu (referenční implementace Pythonu), se kterým se již roky marně bojuje. Třeba PyPy (alternativní interpreter) tímhle netrpí

[pavlix]

Nikoliv, ani tomu tak nebylo.

[Radek Podgorny]

cpython samozrejme vytvari native thready. problem je, ze kvuli gil muze spoustet pythoni kod jen vzdy v jednom z nich (v dany okamzik). pro paralelizaci veci mimo python (rozumej knihovny napsane v cecku) to slouzi skvele... ...a kdyz ne, tak mame multiprocessing.

[kralyk z abclinuxu]

Ok, dík za objasnění...

[pavlix]

To je o těch vlastních vláknech je velmi rozšířená fáma. Ve skutečnosti se jen používá globální zámek pro zpracování pythoního kódu.

[xm]

K čemu stackless v době kdy je tu gevent?

[Bystroushaak]

Je to založené na greenletech, tzn je to zase kooperativní, ne?

[Bystroushaak]

The greenlets all run in the same OS thread and scheduled cooperatively. This means that until a particular greenlet gives up control, by calling a blocking function that will switch to the Hub, other greenlets won’t get a chance to run.

Jo.

[pavlix]

To vadí?

[Bystroushaak]

Tak zrovna u práce s webem tě to nutí používat asynchronní moduly, nebo prostě budeš muset čekat, než se daná věc stáhne. A když už musíš používat asynchronní moduly, tak se to celé stává jaksi zbytečné.

Stackless ti dovoluje používat klasické moduly do té doby, dokud jsou napsané v pythonu a nejedná se o C API. Ty moduly ani neví, že běží paralelně. Já tak můžu používat moje oblíbené knihovny na stahování a parsování a nic dalšího neřešit, protože to za mě řeší Stackless.

[pavlix]

A když už musíš používat asynchronní moduly, tak se to celé stává jaksi zbytečné.

Právě naopak. Ve chvíli, kdy používáš asynchronní IO, to celé dávat smysl začíná.

[Bystroushaak]

Šlo mi spíš o to, že ve chvíli kdy používáš asynchronní knihovny, tak si vystačíš s čistým pythonem (můžeš používat generátory).

[pavlix]

Nějak nechápu, kam míříš.

Já si asynchronní službu představuju jako službu, jejíž základním kamenem je využívání neblokujících volání a hlavní smyčky za pomoci prostředků operačního systému pro čekání na vstup/výstup. Chápu, že asynchronní lze brát i v mnohem širším významu, ale v souvislosti s programováním různých síťových a systémových služeb a nástrojů, si s takto úzkou definicí vystačím a nepotřebuju k tomu preemptivní multitasking.

tak si vystačíš s čistým pythonem

K tomu si vystačíš i bez Pythonu, stačí ti C a pár systémových volání. Nicméně jak obecné C, tak obecný Python trpí tím, že na file descriptorech založené asynchronní knihovny mezi sebou nejdou vždy dobře kombinovat a už vůbec se dobře nekombinují s knihovnami, které používají vlákna, podprocesy a podobné prostředky.

Vidím to tak, že možnosty Pythonu i toho, jak se dneska používá C jsou na tolik špatné, že kdyby se tohle v obou jazycích vyřešilo (včetně interoperability mezi řešením pro C a Python), sníží se vstupní bariéra pro programování komplikovanějších aplikací v obou jazycích natolik, že bych se nebál to nazývat takovou malou programátorskou revolucí. Všiml jsem si, že v Pythonu už se o to nějakým způsobem snaží a chystám se zjistit, co v tomhle ohledu nabízí open source knihovny pro C.

[Mike]

Gevent umožňuje monkey patching všech standardních Python modulů (a v důsledku i externích modulů, protože patchuje takové základní věci jako socket, thread, select, os.fork, atp., aby běhaly ve skutečnosti přes gevent). Je extrémně rychlý (využívá event loop založenou na libevent, která na každé platformě využívá to nejlepší řešení jako backend - epoll na Linuxu, kqueue na FreeBSD, atp.).

Navíc má gevent skvělé jednoduché pythonic API, není to žádné monstrum jako třeba Twisted (ale dokáže s Twisted v případě potřeby spolupracovat). A na rozdíl od Stackless člověk nemusí mít speciální interpreter, je to normální modul do standardního CPythonu.

[JS1]

A co goroutines? To funguje ve srovnani s Stackless Pythonem jak?

[Bystroushaak]

S Go nemám zkušenosti.

[alfonz mucha]

A já si naivně myslel, že kvůli tomuhle mám vždy právě instalovat pypy > abych to nemusel řešit ;)

no nevadí... tak aspoň rychlé výsledky pro normální python kód.

$ time python tests2.py
('starting', 'prvni', 1383050839.110662)
('starting', 'druhy', 1383050839.677418)
('starting', 'treti', 1383050840.239811)
('ending', 'prvni', 1383050847.908535, '-', 8.79787302017212)
('ending', 'treti', 1383050848.091353, '-', 7.851541996002197)
('ending', 'druhy', 1383050848.176817, '-', 8.499398946762085)

real    0m10.093s
user    0m8.557s
sys    0m1.516s

$ time pypy tests2.py
('starting', 'prvni', 1383050858.987054)
('starting', 'druhy', 1383050858.987302)
('starting', 'treti', 1383050858.987473)
('ending', 'prvni', 1383050860.588778, '-', 1.6017239093780518)
('ending', 'treti', 1383050860.58912, '-', 1.601646900177002)
('ending', 'druhy', 1383050860.58933, '-', 1.6020278930664062)

real    0m1.982s
user    0m1.680s
sys    0m0.060s

Já to například dělám tak, že pokud jsou v cestě masivní výpočty, tak nejdříve testuji, jestli je to spustitelné přes pypy. Pokud jo, tak to obvykle dále neřeším. Další možnost beru threading a multiprocessing. Stackless vypadá také pěkně, ale není většinou součástí, takže se může těžko používat. Pypy například již často bývá.

[alfonz mucha]

ještě sem můžeme hodit rychlý výsledek pro python3

$time python3 tests2.py
starting prvni 1383051554.39305
starting druhy 1383051554.393192
starting treti 1383051554.393255
ending prvni 1383051565.460286 - 11.067235946655273
ending treti 1383051565.460516 - 11.067260980606079
ending druhy 1383051565.460628 - 11.06743597984314

real	0m11.192s
user	0m11.141s
sys	0m0.040s

[JS1]

Já to například dělám tak, že pokud jsou v cestě masivní výpočty, tak nejdříve testuji, jestli je to spustitelné přes pypy.

Je rozdil mezi concurrency (jak se tomu rika cesky?) a paralelismem. Viz prednaska.

Concurrency je o tom, jak strukturovat program, aby nemusel cekat na jine casti. Paralelismus je o behu na vice procesorech kvuli vykonu. Blogpost je o concurrency, vase reseni se tyka paralelismu.

[alfonz mucha]

Ok, jasně... to jsem si hned neuvědomil. Stále mi však přijde, že paralelní řešení může řešit problémy concurrency. Jasně ne úplně a ne všechny, ale obvykle to může být řešení dostatečné, ne? Nebo je to jinak?

[JS1]

No, ne vzdycky. Stackless byl tusim treba pouzit v nekterych hrach, kdy kazdy akter bezel ve vlastni korutine. Tam opravdu neslo o paralelismus, ale spis o jednoduchost programovani.

Me by zajimalo, jestli nekdo zkousel takto (na hru, nebo simulaci mnoha agentu) pouzit jazyk Go. Myslim, ze by se to mohlo hodit.

[Bystroushaak]

K pypy jsem se popravdě ještě nedostal, ale už včera jsem si ho na základě diskuze přidal do TODO :)

Stackless vypadá také pěkně, ale není většinou součástí, takže se může těžko používat.

Tohle je aplikace, která poběží jen u mě na serveru, nic co bych sdílel mezi více počítači, takže v tomhle konkrétním případě to není velká vada.

[Bystroushaak]

Support for Stackless and greenlets are now integrated in the normal PyPy. More detailed information is available here.

Pěkné!

[Filip Svoboda]

Tohle mi prijde mega uchylne.. proc nepouzit neblokujici sockety a hlidat je select()em? pripadne je vyhradit do jednoho vlakna...

[Bystroushaak]

Proč jo?

[Filip Svoboda]

+ vyhnes se ztrate vykonu pri prepinani

+ je to standardni vzor kterymu kazdej rozumi

+ nepotrebujes hackovat interpret, tj lepsi kompatibilita

- potrebujes neblokujici knihovny pro zrani io streamu

- jednu smycku v programu atd,..

navic podle me muze to stackless, protoze to bude zahackovany dost v jadru interpretu zpusobit nepekny chyby, ktery bude tezky odladit.

[Bystroushaak]

+ nepotrebujes hackovat interpret, tj lepsi kompatibilita

Přidával jsem to na začátek blogpostu - v pypy je Stackless by default, takže se nic hackovat nemusí.

+ je to standardni vzor kterymu kazdej rozumi

Jo, ale je to hnus (pro mě). A když máš náhodou pracovat s víc asynchronníma knihovnama najednou, tak se to začíná špagetovat. Nehledě na to, že některé knihovny asynchronní imho neseženeš (např. html parser).

+ vyhnes se ztrate vykonu pri prepinani

Ok, tohle beru. Ta ztráta není moc velká, ale u některých aplikací by to vadit mohlo.

navic podle me muze to stackless, protoze to bude zahackovany dost v jadru interpretu zpusobit nepekny chyby, ktery bude tezky odladit.

Tohle je problém, který budu řešit pokud na něj narazím, nemá smysl se nervovat něčím, co dost možná ani neexistuje.

[Filip Svoboda]

v pypy je Stackless by default

OK, chapu, existuje interpret co to ma v sobe.. pro me je python to, co se spusti kdyz napisu do shellu "python", a uplne nejradej mam interprety/technologie ktery fungujou kazdymu naprosto stejne, tj jednou je to "python", tak ma konstantni syntax, zakladni lib set atd.. co kus interpretu to original mi na pythonu z hlediska profesionalniho nasazeni vadi uplne nejvic

Jo, ale je to hnus (pro mě). A když máš náhodou pracovat s víc asynchronníma knihovnama najednou, tak se to začíná špagetovat. Nehledě na to, že některé knihovny asynchronní imho neseženeš (např. html parser).

async http server/klient jsem si musel napsat sam, opravdu je o takovy knihovny nouze (nebo spatne hledam), to je dost velka nevyhoda. kod kterej si takhle stvoris je ale porad 100% ve tvoji moci a nebude ti ho nic nikde prerusovat kdyz nema (samozrejme krome prepinani procesu v OS), tohle ocenis predevsim jakmile zacnes ladit urcity casti kodu pro high-throughtput nebo predevsim low latency response, tam to proste vadi (urcite to ale neni pripad bezneho web crawleru, apod,..)

Tohle je problém, který budu řešit pokud na něj narazím, nemá smysl se nervovat něčím, co dost možná ani neexistuje.

Me moje situace dodavatele prumyslovych reseni mne nuti vytvaret kod kterej nepada a jsem schopnej za nej smluvne rucit (tj ze kod pobezi a nevyskytne se v nem zadna chyba), proto cim vice veci mam v moci a cim mene veci je dynamicky alokovanych/zavislych/rozbitelnych, .. tim lip