[python] cyklus for (bylo superman: zaporny systemovy cas)

[superman]

> 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