Nicméně, asi bych tu debatu ukončil, myslím, že to nespěje k vzájemnému pochopení.
Jen bych na závěr rád přidal link, ve kterém Guido o (volitelné) statické kontrole píše. Že by to nebylo úplně "proti smyslu" jazyka a že by to nebylo úplně nahraditelné dekorátory? Kdo ví :)
Guido take psal, ze by nebylo spatne vyhodit z Pythonu 3 funkcionalni lambda, map(), filter() a reduce() a jak to dopadlo se uz vi. Zvedla se velka vlna nevole a vypadlo nakonec jen reduce(). Takze takovehle Guidovy uvahy moc neznamenaji.
Take je nutno podotknout, ze za tim vasim clankem hned nasledovaly dalsi:
Nejde o to, ze Guido neco ma nebo nema rad. Jde o to, ze samozrejme do (udajne) "dynamickeho" jazyka jdou pridat (udajne) "staticke" prvky. Nejsou to dva neprostoupitelne svety, jak se neustale snazite naznacit. To, ze o tom Guido vazne uvazuje znamena jenom, ze to neni zadna vec typu "tak proc nepouzijte staticky jazyk", jak se mi neustale snazite vnutit.
Navic pridani MOZNOSTI (!!!) otypovani jde udelat jako pouhe rozsireni - bez dopadu na exitstujici kod a bez nutnosti to pouzivat, takze nevim, co Vas tak poburuje. Kdyz se Vam to nelibi, kontrolujte si dal kod rucne.
Python neni dynamicky jazyk udajne, ale fakticky :-). Nikde nenaznacuju, ze to jsou neprostoupitelne svety, naopak jsem vam rikal, ze pokud se vam libi dynamicnost jen vyjimecna, ale predevsim touzite po statickch typech, mate pouzit staticky jazyk a dynamicke chovani implementovat v nem. Co vam celou dobu rikam je, ze Python je dynamicky jazyk, a jestli chcete staticky, pouzijte staticky, na vyber jich je dost a nedelejte staticky i z Pythonu. Uz po nevimkolikate vam doporucuji Boo, ktery je velmi podobny Pythonu, ale ma implementovane staticke promenne a o duck type v nem rovnez neprijdete. Divim se vasemu fanatismu, ze jste si vybral nejaky dynamicky jazyk a rozhodl se presvedcovat siroke okoli, ze by bylo lepsi, kdyby byl staticky, vazne to nechapu :-).
On je trosku problem v tom, zde pokud nejakou slozitejsi funkci neotypujete, tak prekladac v dobe sestavovani bytecode nebude mit vubec tuseni.. a staci vam relativne mala skupina funkci co nema informace o typech a muzete zapomenout na jakoukoliv typovou kontrolu, protoze bud vypisete warning vsude kde se do hry dostalo neco co potencialne interagovalo s "netypovanym" obsahem, nebo ho vsude potlacite. A to uz uzitecne neni. (nemluve o tom, jak to vlastne pred samotnou interpretaci chcete zjistit... to jde jen v opravdu jednoduchych pripadech)
Mit kontrolu typu pomuze na nekterych mistech, ale uz u objektu to nema smysl, protoze i s vylepsenym isinstance a se zavedenim interfaces muzu modifikovat tridu za behu, pripadne predat neco co ma stejne api, ale spolecneho predka to nikdy nevidelo. (a to uz je hodne caste).
Takze jde o to jestli bych nakonec nebyl zahlcen varovanimi a nezacal je ignorovat.. pylint/pychecker mi jich dava dost i ted a nastesti ma informace o interpretaci, takze typove konflikty celkem pohlida
A malem bych zapomnel na muj oblibeny modul imp a dynamicky import za behu.. tam uz z principu neni mozne pohlidat typy pri spusteni (a neumi to ani cecko.. a c++ jen omylem diky kodovani nazvu symbolu ;)
Opět opakuji princip Ojectiv C: co je otypovane kontrolovat, co neni, ponechat runtimu. A hle, ve standardni knihovne je otypovane temer vse, protoze temer u vsech standardnich problemu je otypovani mozne.