> GvR nikomu nebrání vytvořit mnohem dokonalejší > odnož Pythonu. Čeká jen na tebe.
Existuje několik odnoží Pythonu, například JPython, ten od GvR je z nich nejpomalejší. > Pokud jakákoliv konstrukce větvení nebo cyklu > neprovádí testy a jiné příkazy způsobem, který > by mohl mít za následek vedlejší efekt, a pokud > je tělo takové konstrukce prázdné, dá se úplně > vynechat. Pokud testy volají funkci, pak jste s optimalizací skončil. A for cyklus v Pythonu je veden tímto směrem, dokonce range má v budoucnu vracet iterátor, tedy funkci. > Ani v jazycích C/C++ neexistuje klasický cyklus > for. A co je to vůbec klasický cyklus for? > Ten co zavedl (nebo převzal) Pascal? > Pro objektový přístup, který využívá různé > typy kontejnerů (nejen pole) je průchod přes > indexy příliš speciální. Python, který i pro cyklus přes lineární číselnou řadu musí vytvářet sekvenci, nebo iterátor je jen překážkou pro optimalizaci. Samozřejmě to jde optimalizovat, ale je potřeba vědět speciální objekty a sekvence a vidět dovnitř, tedy je to špinavý přístup. > Pokud vím, je gramatika Pythonu LL(1) a v takovém > případě může být pro interpret efektivnější > (z hlediska rychlosti tvorby a snadnosti údržby) > použít překlad rekurzivním sestupem. Už jsem z toho > trochu vypadl. Opravte mě, pokud se pletu. Efektivnější z hlediska snadnosti údržby je vždycky použití speciálních nástrojů pokud fungují dobře a vymýšlel je někdo kdo skutečně chce usnadnit práci. Z hlediska rychlosti tvorby také. Dám jiný příklad, je efektivnější pro práci s daty, když chcete pracovat s obrovským počtem údajů použít hotovou databázi, řekněme Oracle, nebo si celou práci nabastlit sám? Včetně práci s diskovými stránkami, tvorbou optimalizovaných dat, konstrukcí B stromů a indexů, a super optimalizovanými algoritmy pro práci s daty? Na 100% zjistíte, že použití hotové rozumné relační databáze znamená rychlejší práci s daty, efektivnější využití místa na disku, větší možnosti a větší spolehlivost. A to i kdybyste svojí práci s daty bastlil půl roku. Stejně tak je to s parserem a gramatikou psanou ručně. Znám dva jazyky o kterých to vím, a oba trpí omezením pro zdrojový kód i jinde. Ani gcc nemá pro všechny jazyky ručně psanou gramatiku a používá lex + yacc, a to jsou naprosto nejhorší nástroje, existují mnohem lepší. A jak je to s efektivitou? Databáze sqlite se rozhodla, že nebude sql příkazy parsovat ručně, ale použije hotový generátor gramatiky, nevím ani jak se jmenuje. Problémy s tím nejsou, je to malé, rychlé, efektivní a hlavně to funguje na 100%!!! A autor se mohl soustředit na to, aby databáze byla lepší. Při prohlížení manuálu k Pythonu se nemůžu zbavit dojmu, že značný čas věnuje GvR právě parseru plus gramatice. Namísto toho by mohl zlepšit věci jinde. Nemusel by třeba vyhazovat konstrukce jen proto, že jeho horší gramatika, nebo větší náročnost tvorby gramatiky už prostě nestíhá. Všimněte si, že v Pythonu je dost knihoven pro spojení Pythonu s vnitřním formátem pythonovské gramatiky - token a spol.. a to je špatně. Protože až se změní vnitřní gramatika, tak co? Miloslav Ponkrác _______________________________________________ Python mailing list [email protected] http://www.py.cz/mailman/listinfo/python
