Vlákno názorů k článku
Vyšel Python 3.0 od M. Prýmek - Nějak jsem poslední dobou vývoj Pythonu nesledoval, takže...

> Tak ja to neresim, protoze podobne chyby me nepotkavaji, prinejmensim si nejsem vedom "strasne tezkeho dohledavani" takove chyby.

Vam se nikdy nestalo, ze jste sbiral data z ruznych zdroju do jedne struktury (treba pole) a pouzival nekde uplne jinde - kde se teprve ta chyba objevi? Zjistovat, odkud se tam zrovna tahle chybna hodnota vzala, je obcas dost o nervy - ale je pravda, ze casto se to nestava.

> Ti co s tim maji problem to mohou snadno resit pomoci dekoratorua

Dekorator je prece jen spustitelny kod, ne deklarace - cili v nejlepsim pripade se da pouzit jako zkratka pro assert(...), assert(...),...

> Znate treba pychecker nebo pylint?
Priznam se bez muceni, ze neznal (nebo si alespon nepamatuju). PyLint vypada dobre. Dik za tip.

Ne, nic takoveho si nevybavuji a kdybych se nejakou takovou "strasne tezko dohledatelnou" chybou trapil, pamatoval bych si to.

Ano, smysl dekoratoru je v jeho krasne prehlednosti a intuitivnimu snadnemu pouziti. Zadnou novou funkcionalitu do pythonu neprinesl, jen to udelal srozumitelnejsi a prehlednejsi. Ale pointa je v necem jinem, to co chcete a co Python diky sve dynamicke podstate umoznuje, toho snadno dosahnete pomoci dekoratoru.

Myslíte si, že je vhodné každou funkci/metodu začít třeba pěti asserty? (nebo něčím ještě silnějším, co bude fungovat i v ne-debug módu)? I v situaci, kdy funkcí je každý přiblblý getter/setter?

Od toho mate prave ten dekorator, ktery vam to cele vyrazne usnadni. Jedno z moznych flexibilnich reseni vypada napr. takto:

@require("x", int, float)
@require("y", float)
def foo(x, y):
    return x+y

http://code.activestate.com/recipes/454322/

Lze si predstavit i pozicni reseni:

@checktype((int, float), float)
def foo(x, y):
    return x+y

A co to znamena v praxi? Ze se treba v ramci deseti volani funkci bude desetkrat kontrolovat, zda jedna stale stejna promenna, ktera se ani nemohla zmenit, protoze jsem ji nic neprirazoval, ma stale ten samy typ :)

Ano, u dynamickeho silne typovaneho jazyka je to z jeho podstaty nutnost. Kontrola se dela za behu, to je vlastnost, nikoli chyba, techto jazyku.

To není nutnost, ale rozhodnutí. Tímpádem je to samozřejmě možné nazvat "vlastností". Stejně tak by se Rossum mohl třeba rozhodnout, že Python nebude obsahovat typ string. Taky by to byla "vlastnost".

Rozhodnuti je, zda jazyk bude dynamicky nebo staticky, jestlize je rozhodnuto, ze bude silne a dynamicky typovany, tak z toho uz vyplyvaji jiste nutnosti, jako napriklad, ze kontrola typu se dela za behu.

Ano. Tohle je presne situace, kdy by se hodil offline checker.

Nikoli, tohle je presne situace, kdy bud poctive testujete, nebo se vzdate flexibility jazyka s dynamickym typovanim a zacnete pouzivat jazyk se statickym typovanim. U dynamickeho jazyka v dobe prekladu neni a nemuze byt typ promenne znam a byt kontrolovan. To je zakladni vlastnost dynamickych jazyku, podle niz se (vsimnete si) dokonce nazyvaji. Je zbytecne proti tomu brojit, jestli vam to nevyhovuje, pouzivejte jazyky staticke. Mohu vam doporucit Adu, kde muzete kontrolovat nejen datovy typ, ale i rozsah promenne.

No super! Přesně na tohle jsem se ptal - ve What's new jsem to přehlídl. Dík.

Akorátže zas je v tom trochu moc velká volnost, ale pokud člověk chce, tak to využije.

No vidite a ja myslel ze jste se ptal na staticke typovani :-). Jestli vam staci tohle, tak to je fajn, ale myslel jsem, ze s timhle byste me poslal do haje, kdyz to nic neumi :-).

Nic to neumí dokud není definován standardní způsob anotace a není anotována standardní knihovna, což je pohříchu právě současný stav :)

To ano, ale anotace neni deklarace datoveho typu a uz vubec neznamena jeho kontrolu at za behu nebo dokonce pri kompilaci. Anotovat lze parametry jakkoli a zalezi ciste na programatorovi, jak tato pridruzena metadata vyuzije.

> U dynamickeho jazyka v dobe prekladu neni a nemuze byt typ promenne znam a byt kontrolovan.

To je zbytečně ideologické myšlení.

Prostě i v dynamickém jazyce, kterým Python je, se typ u velké části proměnných dá zjistit inferencí.

Prostě pokud mám funkci/metodu, která má jasně dané vstupní typy a uvnitř používá jen otypované funkce,
jsou výsledek i všechny mezivýsledky opět jasně otypované.

To, že toho Python nevyužívá s poukazem na to, že je "přece dynamický", NENÍ VÝHODA. Je to prostě nevyužití potenciálu a rozšíření prostoru pro chyby, které se zjistí až za běhu...

Mimochodem, proměnných, které nejsou otypovatelné inferencí, bude v typickém programu minimum: jen ty, které přiletí z ne-standardně-knihovních funkcí, ze souboru, sítě apod.

Nevidím důvod, proč by funkce std. knihovny nedeklarovaly vůči okolí svoje otypování, protože beztak vnitřně typ kontrolují...

Nikoli, to je logicke mysleni. Python pri prekladu proste nevi, jaky typ promenna behem chodu bude mit, tudiz si muzete ve sve funkci deklarovat poctive cokoli, tu kontrolu stejne neni mozno pri prekladu provest. Uvedomte si, ze v Pythonu se za behu muze zmenit i funkce nebo trida, ani ty nejsou staticke. Toho ceho chcete dosahnout dosahnete jen tim, ze zakazete dynamicke prvky jazyka.

To ze by Python mohl mit staticke typy je pravda, ale prastal by byt dynamicky. To jestli JE nebo NENI VYHODA ze je Python dynamicky je ciste subjektivni nazor. Jestli vam vyhovuji staticke jazyky, proc si nevyberete nejaky staticky? Proc mate neustale potrebu delat z Pythonu staticky jazyk?

Jestli se vam libi syntaxe Pythonu, tak pouzivejte treba staticky typovany Boo, ktery je jinak Pythonu velmi podobny.

Jak jsem již řekl, v praxi je drtivá většina proměnných typově statická. A ALESPOŇ ty by mohl interpret či offline checker kontrolovat (ano, typove signatury + pylint je asi to, co mam namysli*).

Mám-li

for i in range...
s = i[0]

a interpret to odhali az pri behu, neni to vyhoda jazyka. Je to nevyuziti kontroly, ktera by s klidem mohla probehnout.

Ale na tom se asi neshodneme, je zbytecne se opakovat donekonecna, takze ja koncim a preji pekny den :)

* ovsem s tou vyhradou, ze smysl to zacne mit az tehdy, kdyz budou otypovane standardni funkce, protoze ty se pouzivaji nejcasteji. A bohuzel navrzeny zpusob typove anotace pouze umoznuje - nestandardizuje, takze efekt to mit nebude

Čili považujete za "výhodu" Pythonu, že nevypíše varování (např. v nějakém debug módu nebo tak) u konstrukce

for i in range(0,5): print i[0]

ale počká si, dokud program do tohoto bodu nedospěje?

Já to teda za výhodu nepovažuju.

Ne nutně. Viz "tečka" níže.

V Pythonu jsou všechny promenne bez vyjimky dynamicke, nevim jak jste prisel na to, ze vetsina z nich je staticka. Python staticke promenne neumi.

Jestli tim chcete naznacit, ze vy dynamickych vlastnosti jazyka nevyuzivate, tak to je vas problem a mel byste se nad sebou zamyslet. Ja jich treba vyuzivam velmi casto. Moje funkce casto vraci nejakou datovou stukturu, nebo false pri selhani nebo null, kdyz data nejsou. To jsou tri ruzne datove typy. Nebo z duvodu rychlosti skladam retezec pomoci pole, a pak nad nim udelam join a vlozim ho do stejne promenne.

Pokud dynamicke vlastnosti nevyuzivate, tak se zbytecne omezujete a ochuzujete. Neni mi jasne, proc potom vlaste pouzivate dynamicky jazyk, kdyz je vam blizsi staticky a jeho vyhody? Proc na misto pouzivani statickeho jazyka chcete, aby Python zavedl staticke promenne? Nebude lepsi, kdyz radsi zmenite jazyk? Neodpovedel jste mi, proc nepouzivate jazyk Boo? Kdyz tento je odvozen z Pythonu, ma tarka totoznou syntaxi, ale na rozdil od Pythonu ma staticke promenne.

Opravdu nechapu vas pristup, vzdychate po vyhodach statickeho jazyka, vzdavate se vyhody dynamickych jazyku, navzdory tomu pouzivate dynamicky Python (takze nemate vyhody ani jednoho z pristupu) a chcete aby se z nej stal staticky jazyk, prestoze uz nekdo udelal statickou variantu Pythonu a nazval ji Boo.

Dokud Python nebude staticky (a ja verim ze nikdy), tak v nem nikdy neudelate spolehlivou kontrolu datovych typu pri prekladu. A pokud ta kontrola nebude spolehliva, tak se stejne nevyhnete klasickemu osetreni takovych chyb. Tudiz si zadnou praci neusetrite.

A k vasemu prikladu, range neni prikaz ale funkce, tudiz muze byt dynamicky pretypovan, tedy za behu programu. Sice se to bezne nepouziva, ale vyloucit to nemuzete, nemuze to vyloucit ani interpret, tudiz ac si myslite, ze to pri prekladu zkontrolovat jde, tak se mylite, spolehlive nikoli.

> V Pythonu jsou všechny promenne bez vyjimky dynamicke, nevim jak jste prisel na to, ze vetsina z nich je staticka. Python staticke promenne neumi.

Mám-li proměnnou surname, dateOfBirth nebo billGatesSallary, tak to jsou v Pythony sice formalne dynamicke promenne, ale fakticky tam nema co delat nic jineho nez string, date, Decimal. Jestli tam neco jineho je, je to zjevna chyba a bylo by super, kdyby pylint umel upozornit na obrat, kde se tam cpe ZJEVNE neco jineho. Pokud se tam cpe neco, o cem pylint nevi, co by to mohlo byt, pak samozrejme upozornit nemuze/nemusi.

> Jestli tim chcete naznacit, ze vy dynamickych vlastnosti jazyka nevyuzivate,

Pouzivam velmi, vcetne napr. run time kompilace a nahrazovani metod. Vy mi ale porad nerozumite v jedne veci - jsou promenne, kde z definice (z logiky programu) ocekavam COKOLI a jsou casti, kde ocekavam pouze NECO KONKRETNIHO. Moznost upozornit na casti, kde je ZJEVNE NECO JINEHO KONKRETNIHO bych povazoval za plus. Nic vic, nic min.

> Neodpovedel jste mi, proc nepouzivate jazyk Boo?

Jednoduse proto, ze je to nad CLI. Pokud by existoval Boo nad pythonnimi knihovnami a runtimem, bezpochyby bych ho pouzival.

> uz nekdo udelal statickou variantu Pythonu a nazval ji Boo.

To neni pravda. Boo je alternativa C#, coz je trochu neco jineho nez python (predevsim z praktickeho hlediska instalace knihoven atd.).

> vzdychate po vyhodach statickeho jazyka,

Ne. Je to jako problem aproximace: tam, kde je mozne vymyslet presny algoritmus, bezpochyby MUSI byt pouzit. Tam, kde ho nemame, pouzijeme nejakou "soft" metodu (treba NN). Pouzivat ale NN pro hledani maxima derivovatelne funkce je ale trochu srandovni, ne?

Obdobne to myslim ja: kde by bylo mozne pouzit kontrolu typu, proc ji nepouzit? Kde ji neni mozne pouzit, tam proste musime skoncit u realtime chyb.

> Dokud Python nebude staticky (a ja verim ze nikdy), tak v nem nikdy neudelate spolehlivou kontrolu datovych typu pri prekladu.

Odpoved je stejna. Nejde o spolehlivou kontrolu vsude, ale o kontrolu tam, kde je to mozne.

>A k vasemu prikladu, range neni prikaz ale funkce, tudiz muze byt dynamicky pretypovan, tedy za behu programu.

Ano muze. Ovsem nebudeme vycitat off-line checkeru, ze zanedbava moznost, ze programator je natolik blazen, ze prekryje range - a jeste k tomu typove nekompatibilne...

To neni formalne, to jsou realne dynamicke promenne. Porad se snazite zavest do dynamickeho jazyka staticke promenne. Je-li v tech promennych neco jineho, pro Python to prave zjevna chyba neni.

Pochopte to uz konecne. I kdyz u parametru funkce budete deklarovat, ze by tam mel byt int, tak je to dobre jen pro kontrolu, zda te funkci nepredavate hodnotu s nekompatibilnim datovym typem, a to muzete udelat i treba pomoci toho dekoratoru. Timto nedocilite toho, ze by ta promenna byla staticka, ze by ji byl jednoznacne urcen datovy typ, ktery muze obsahovat. Tuto informaci si promenne v Pythonu s sebou nenesou, naopak, datovy typ si s sebou nese hodnota. To je zasadni rozdil mezi dynamicky a staticky typovanym jazykem.

K tomu co chcete by bylo nutno zavest do Pythonu staticke promenne a deklarovat jim datove typy jako v jinych jazycich. Dedy pripojit informaci o datovem typu k promenne na misto k hodnote, tedy udelat z Pythonu staticky typovany jazyk. Teprve pak by Python pri prekladu vedel, ze v teto promenne muze byt jen takovy a makovy datovy typ.

CITUJI: Ano muze. Ovsem nebudeme vycitat off-line checkeru, ze zanedbava moznost, ze programator je natolik blazen, ze prekryje range - a jeste k tomu typove nekompatibilne...

Ja mu to vycitat samozrejme budu, protoze mi bude hlasit chybu tam kde neni. To je totiz zjevna chyba toho checkeru. To take znamena, ze tuto kontrolu nemuze delat sam interpret, protoze by se slo jen tezko smirit s tim, ze vam Python hlasi falesne chyby v kodu nebo ho dokonce odmita prelozit. Smirte se se skutecnosti, ze u dynamickeho jazyka se typova kontrola dela za behu programu a ze se to resi dukladnym testovanim, k cemuz Python poskytuje prislusne prostredky, viz. napriklad moduly unittest nebo doctest.

Zcela uprimne, nez nespolehliva kontrola, to je lepsi zadna kontrola, pak programator vi, ze si musi kontrolu zajistit sam. On by ji mel resit i u statickych jazyku a podivjte se, jak to v praxi vypada, kdyz to proleze prekladacem, tak je to uz dobry. Pritom prekladacem statickeho jazyka klidne prolezou takveto zverstva:

#include <stdio.h>
int main(int *argc, char *argv[]){
  printf("Vysledek = %d\n", (1+"1"));
  return(0);
}

A neprijdete na to spolehlive ani za behu programu, protoze Vysledek = 134513793, kdezto Python by vam alespon vyhodil vyjimku, ze int a str nelze scitat s tim kde a jak se to presne stalo. A pak takovou chybu u statickeho jazyka hledejte. Co ze jste to psal o strasne tezkem dohledani chyby u Pythonu?

Takze o co vlastne jde? Nemohu se zbavit dojmu, ze jen o lenost. O tu samou lenost, kvuli ktere programatori ve staticych jazycich dukladne nekontroluji sve zdrojaky, protoze to prece prekladac dela za ne. A kdyby neco takoveho delal i Python, ale o nekolik radu mene spolehliveji, tak by to dopadlo imho velmi katastrofalne.

V cem je problem, ze Boo bezi nad CLI? je prece uplne jedno, jestli ma vlastni runtime jako Python nebo pouziva nejaky univerzalni runtime. Jestlize chcete statickou (pri prekladu) typovou kontrolu, nic jineho nez staticky jazyk vam nezbyva.

> I kdyz u parametru funkce budete deklarovat, ze by tam mel byt int, tak je to dobre jen pro kontrolu, zda te funkci nepredavate hodnotu s nekompatibilnim datovym typem, a to muzete udelat i treba pomoci toho dekoratoru.

Ne. Dekorátor je stále věci runtime. Dá se sice použít jako "signatura", kterou je možné offline kontrolovat, ale to se dá využít i komentář - a opět opakuji - klíčem je, zda signatury mají funkce standardní knihovny. Bez toho je efekt nulový.

> K tomu co chcete by bylo nutno zavest do Pythonu staticke promenne

Ne. Viz Objective C: typ "id" znamená "libovolný objekt". Dá se potom přetypovat na konkrétní, třeba NSMutableString, který už dále umožňuje "statickou" kontrolu.

Prostě a jednoduše "statický" a "dynamický" jsou jen kouzelná slovíčka. V praxi se oba přístupy dají kombinovat a je to efektivní.

> Ja mu to vycitat samozrejme budu, protoze mi bude hlasit chybu tam kde neni.

Warning není chyba. Off-line warning není runtime chyba. Warningy se dají potlačit tam, kde je to potřeba. Viz javové "warning possible fall-through" pro chybný case.

> Zcela uprimne, nez nespolehliva kontrola, to je lepsi zadna kontrola,

Taky názor.

> a ze se to resi dukladnym testovanim,

Runtimové testování nikdy nemůže nahradit testování formální.

> Pritom prekladacem statickeho jazyka klidne prolezou takveto zverstva

To je především zvěrstvo C, které se jmenuje "implicitní přetypování" a je to opravdu zvěrstvo.

Dekoratory mohou mit i funkce standardni knihovny, to je z tohodle pohledu pras jako uhod. A na kontrolu za behu jste odkazany vzdy, tomu se jednoduse nevyhnete. Tecka.

Staicky a dynamicky nejsou kouzelna slovicka, ale jasne definuji, jak jazyk zachazi s datovymi typy, promenymi a hodnotami. Rozdil neni v tom, jestli staticky typ muze byt univerzalni void nebo ne, ale kdo si s sebou nese informaci o typu, bud promenna nebo hodnota. Vy chcete, aby si ji nesla promenna, coz je staticky pristup, Python je ale dynamicky a informaci o typu si u nej nese hodnota. Chapete ten rozdil?

CITUJI: Runtimové testování nikdy nemůže nahradit testování formální.

Tak to si zasluhuje sirsi vysvetelni :-)). Ja si dukladnou vlastni (vytvorenou programatorem) kontrolu funkcnosti programu dovedu docela dobre predstavit i s tim, ze nahradi kontrolu, kterou provadi prekladac. Ale nedovedu si predstavit, ze by prekladac dovedl provest kontrolu v plne mire, v jake ji dokaze provest programator :-). To by totiz znamenalo, ze prekladac je obdaren umelou inteligenci a chape, co ma program delat misto toho, co dela. Kontrola prekladacem je nutne omezena a nedostatecna. Takze jedina nezytna a nenahraditelna kontrola prekladacem je kontrola zapisu programu, nikoli jeho funkce.

Jsem rad, ze se shodneme na tom, ze programator tak jako tak musi kontrolovat program sam a nemuze se spolehat na prekladac. A jestlize uz programator tu kontrolu dela, je zbytecne aby ji delal i prekladac, zvlaste v pripade dynamickeho jazyka, kde kontrola typu je z podstaty nespolehliva a muze snadno vest k falesnym vysledkum. Takova kontrola nema smysl a jen skodi veci.

> Ale nedovedu si predstavit, ze by prekladac dovedl provest kontrolu v plne mire, v jake ji dokaze provest programator :-).

Já si taky nedovedu představit, že by ohrádka dokázala dítě ochránit stejně dobře jako člověk, který ho hlídá. Přesto ji nezavrhneme jako zbytečnou, že?

> Chapete ten rozdil?

Ano, chápu. Vy ale nechápete, že "statický" či "dynamický" není NUTNĚ vlastností jazyka jako takového, ale především vlastností konkrétního kusu kódu. Samozřejmě pokud chceme, můžeme i JAZYK prohlásit za "pouze dynamický", ale to není otázka nutnosti, ale ROZHODNUTÍ.

Obrat "proměnná nese typ" je taky nesmysl. Proměnná je buď otypovaná ("osignaturovaná") nebo není. Zbytek je otázka inference. V některých jazycích kazždá proměnná MUSÍ být otypovaná, v některých MŮŽE být a v některých (Python) NEMŮŽE (neexistuje plodný způsob). Toť onen rozdíl. Jazyky, kde nemůže být je možné rozšířit tak, aby mohla být - a to logicky bez ztráty expresivity.

Díky za diskusi, dál nepovažuji za plodné v ní pokračovat. Viz příspěvek "Tečka".

Nespolehlivou ohradku, ktera sama je pro dite nebezpecna jako zbytecnou zavrhnu.

Staticky nebo dynamicky je nutne vlastnosti jazyka jako takoveho, je to zpusob jeho vnitrni implementace. To ze vy nahodou ve sve dynamicke promenne datovy typ nemenite z ni z pohledu interpretu nedela statickou promennou a tudiz vam ji nemuze kontrolovat. Samozrejme, ze neni nutne, aby Python byl dynamicky, je to skutecne zalezitost rozhodnuti jeho tvurcu, kteri v pripade Pythonu rozhodli, ze bude dynamicky a tak jej implementovali. Tvurci jazyka Boo se rozhodli, ze bude jako Python ale bude staticky. A na vas je ted rozhodnout, jaky z nich si vyberete. Jestlize si vyberete dynamicky a pak neustale dokola opakujete, ze by bylo lepsi, kdyby byl staticky, tak nevim co uz vam na to rict.

Jde o to, ze jakmile se neco pretypuje z id, tak uz probiha normalni prisna typova kontrola, zatimco o id se jakoby "nevi nic". Id je de facto stejne jako v pythonu, akoratze python ma JEN to - a o to jde.

Python nema jen Id. Python ma radu datovych typu, ale tyto jsou sdruzeny s hodnotou a ne promennou, jako je tomu u statickych jazyku. A tohle asi nebude pripad Objective C, ze? Ja ho neznam, ale predpokladam, ze je to staticky jazyk a Id je tedy neco jako Void, tedy ukazatel do pameti na neco o cem prekladac nevi co to je a tak to nekontroluje. V takovem pripade to neni stejne jako v Pythonu.

Nebo kdyz budete mit dve Id promenne, jedna bude obsahovat cislo, druha text, vyhodi Objective C vyjimku, ze text s cislem nejde scitat, jako to udela Python? Nevim, ale predpokladam ze ne.

Proste tohle jsou uplne jine pristupy a je falesne srovnavat to dohromady a rikat, ze Python ma jen nejakou minimalni podmnozinu funkcnosti z Objective C.

Funguje to zhruba takhle: mám-li proměnnou typu id, překladač nic nekontroluje (stejně jako Python).

Mám-li objekt třídy X, která umí zpracovat zprávy A a B, tak v případě poslání zprávy C vypíše překladač varování (ne chybu!), že objekt typu X pravděpodobně nebude umět zprávu C zpracovat.

Čili varování je vydáno tam, kde vydáno být může a k runtime chybě dojde v případě, kdy daný objekt skutečně neumí zpracovat zprávu - tedy např. neumí k sobě (stringu) přičíst číslo.

Jestli tohle není nadmnožina chování Pythonu, tak jsem z toho teda jelen :)

viz http://www.mujmac.cz/art/start/cocoa_4.html, zejmena tahle pasaz, ktera ukazuje, co Python nema a bez ztraty expresivity by mit mohl:

Je důležité mít na paměti, že se jedná jen o informaci pro překladač a o nic jiného! Za běhu pak díky pozdní vazbě může libovolný objekt dostat libovolnou zprávu, zcela bez ohledu na to, jestli je zapsaná v jeho rozhraní nebo ne. Stejně snadno také můžeme používat i zprávy, jež nejsou zapsané v žádném rozhraní: překladač pak považuje jejich návratové hodnoty i jejich případné argumenty za objekty (tedy typy id) – což znamená, že to stejně dobře může být cokoli, co se dá na id bez ztráty převést (typicky int či obecný ukazatel na cokoli). Totéž platí pro návratové hodnoty nebo argumenty, u kterých žádný typ v závorce neuvedeme. (Pro pohodlí a zabezpečení proti překlepům překladač v takovýchto případech obvykle zobrazuje varování; přeložený kód je však opět naprosto korektní.)

Vidíme, že Objective C je, alespoň pokud zůstaneme jen u objektů a tříd a ponecháme stranou klasické C, v zásadě beztypový jazyk: všechny objekty jsou téhož typu (totiž id/Class); to, že mohou být instancemi různých tříd či třídami samotnými, se projeví až za běhu, a to jen a jenom tím, kterým zprávám rozumějí a kterým ne. Skutečně tomu přesně tak je; pro pohodlí programátorů však existuje možnost, jak překladači sdělit, že objekt je instancí některé konkrétní třídy: deklarujeme jej jako "ukazatel na třídu":

MyClass *obj; // v podstatě totéž, jako "id obj"

Překladač – a teď pozor – v podstatě přeloží vše přesně stejně, jako kdybychom použili obecnou deklaraci id obj; jediný rozdíl je v tom, že hlídá, zda neposíláme objektu obj zprávy, jež nejsou v rozhraní třídy MyClass, a pokud ano, vypíše varování (ale opět vše přeloží korektně, a pokud objekt ve skutečnosti dané zprávě rozumí, vše také korektně poběží).

Jak jsem poznamenal, Objective C neznam, a to co jsem o nem psal jsem uvadel jako svuj predpoklad. Ty tedy byly spatne. Porad mi to ale neni jasne. V pyhonu mohu napriklad napsat:

aa = 1
bb = aa + 1

V Objective C to bude asi takto:

id aa = 1
id bb = aa + 1

Protoze se pouziva pozdni vazba, prekladac nevi jaky typ ma promm. aa a bude mi vypisovat varovani? Tj. chtel byste aby u vyse uvedeneho kodu Python vypisoval varovani? Jestli Objective C splnuje vase naroky na programovaci jazyk, proc tedy nepouzivate tento a snazite se pretvorit Python k obrazu svemu?

Varovani se vypisuje POUZE v případě, že se VÍ (tj. je deklarováno), jaký je typ. V případě, že se to neví, se předpokládá, že "vše je dovoleno".

> proc tedy nepouzivate tento a snazite se pretvorit Python k obrazu svemu?

Nic nepředělávám k obrazu svému. Nenapsal jsem ani řádku interpretu pythonu a ani jeden PEP. Pouze konstatuju, že existují dynamické jazyky, které nabízí MOŽNOST dělat kontroly (varování!) tam, kde to programátor chce.

BTW: moznost deklarovat a kontrolovat typ tam, kde je to mozne, neznamena vubec vzdat se dynamicnosti. Boo samozrejme taky umni dynamicke typy (duck typing), podobne je tomu napr. u Objective C. Oba jazyky oproti Pythonu umoznuji lepsi kontrolu, kde je to mozne, a stejnou dynamicnost tam, kde je to potreba.

A k cemu je dobra nespolehliva kontrola, kdyz to znamena, ze programator stejne musi provest dukladnou kontrolu sam?

Chyby jsou několika typů, zejména:

1. odhalitelné formálně
2. odhalitelné za běhu

všechny ad 1 jsou také ad 2, ale ne opačně. Čili můj názor je, že na co je formálně možné upozornit PŘED BĚHEM, na to by mělo být upozorněno.

Ale neodpovedel jste mi, k cemu je to dobre, kdyz vite, ze to nemuze byt spolehlive a stejne si to musite kontrolovat sam? Ja se domnivam ze radu programatoru by to vedlo k pohodlnosti a zanedbani vlastni kontroly, tim padem k nespolehlivejsim programum napsanych v Pythonu a zhorseni jeho povesti. Takovou spatnou povest si ziskala treba Java (z duvodu systemovych naroku) a nasledky si na desktopu nese dodnes. Kontrola na kterou se nemohu spolehnout je k nicemu, kontrola, ktera mi bude davat falesne informace o chybach je uz vylozene skodliva.

BTW2:

Tvrzení "většina je de facto statická" je možné si ověřit letmým pohledem na standardní knihovnu (a jistě nebudete podezřívat autory std.knihovny, že "dostatečně nevyužívají dynamičnosti").

Kolik procent funkcí a metod vrací či přijímá "různé typy"? (tj. typy, které nemají společného objektového předka? - a mimochodem - None není "třetí typ", jak jste psal, ale legitimní hodnota libovolného objektového typu).

Vracet či přijímat dva typy, které nemají nic společného (tj. ani "duck type" definovatelný např. formou rozhranní, či jak to nazývá Objective C "protokolu"), je zjevná programátorská prasárna, která je ve větším projektu těžko udržitelná.

Napadá mě akorát třeba pickle.load nebo __getitem__ :) - ovšem u druhého to není ani nutné ani zvlášť praktické, jak dokazuje Java nebo Objective C.

CITUJI: mimochodem - None není "třetí typ", jak jste psal, ale legitimní hodnota libovolného objektového typu Za prve jsem psal o null (ktere je v PHP, v Pythonu nevracim False, ale vyhazuji vyjimku), za druhe None ma vlastni datovy typ NoneType s jedinou hodnotou None. Tudiz to je treti datovy typ, ktery by funkce nemohla vracet, kdyby mela deklarovano, ze vraci datovy typ list, kuprikladu.

>>> type([]), type(False), type(None)
(<class 'list'>, <class 'bool'>, <class 'NoneType'>)

To je ovšem právě proto, že není nutnost "statické" kontroly formální správnosti kódu. Ve všech jiných jazycích, které znám, a které aspoň nějakou kontrolu umožňují, je None/null/nil/... hodnotou libovolného objektového typu.

Obrat "funkce vrátí objekt, který ..., nebo nil" je naprosto běžný a legitimní.

Nevim proc mi to rikate, ja jen dokazuji, ze None je treti datovy typ, coz jste poprel.

Jestlize v jinych jazycich muze funkce, ktera ma vratit treba pole, vratit neco jineho, pak jste na tom uplne stejne jako u Pythonu, navratovou hodnotu musite kontrolovat za behu a prekladac vas neupozorni na to, ze se dopoustite chyby typu None[1].

Tim padem mi uz neni vubec jasne, co vlastne resite. Kontrolu za behu musite delat naprosto vsude. Doted jsem si ale myslel, ze pokrocilejsi jazyky vyvolaji vyjimku, takze se muzete spolehnout na to, co funkce/metoda vraci a nemusite u nich navratovou hodnotu testovat. Alespon tak to resim ja v Pythonu. Testovat navratove hodnoty je takovy archaicky zvyk z jazyku, ktere nepodporuji vyjimky. Nebo ne?

CITUJI: Vracet či přijímat dva typy, které nemají nic společného (tj. ani "duck type" definovatelný např. formou rozhranní, či jak to nazývá Objective C "protokolu"), je zjevná programátorská prasárna, která je ve větším projektu těžko udržitelná.

V tom pripade vam nic nebrani pouzivat staticky jazyk. A brat to tak, ze vsechny dynamicke jazyky jsou jen pro prasacke programatory, kdyz vyuzivani jejich zakladni vlastnosti, tj. dynamickych typu, je dle vas prasarna :-).

Dejme tomu, že v jedné třídě ze sta, které v projektu mám, chci měnit za běhu metody.

Je nutné kvůli téhle jedné metodě absolutně rezignovat na typovou kontrolu v celém projektu? Není.

P.S. jaký největší projekt jste v Pythonu psal? To je asi klíčová otázka.

Neni, ale v jedne tride ze sta toho dosahnete i ve staticky typovanem jazyku, akorat je to mene pohodlnejsi. Kvuli takovemu pripadu nemusite pouzivat dynamicky jazyk. A pokud techto pripadu mate hodne a vyplati se vam pro to pouzit dynamicky jazyk, pak je uz zase zbytecne se zabyvat statickou typovou kontrolou.

Ad dotaz. Ono to neni o Pythonu, ale o umeni pouzivat dynamicke jazyky jako takove. Rada programatoru, kteri vyrostli a naucili se programovat na statickych proste ty dynamicke neumi moc pouzivat a nesedi jim. Ja jsem sice zacal s Ceckem, ale nikdy jsem v nem nic velkeho nedelal a zahy jsem presel na ty dynamicke, ktere mi vyhovuji vic, protoze jsou vyrazne produktivnejsi. Dneska bych Cecko pouzival jen s odporem a zajimal jsem se i o Javu a C#, ale ty zase nesedi me. Nicmene do nich nekafram a netvrdim, ze by se meli inspirovat u Pythonu a prejmout jejich rysy, aby mi vyhovovali. Proste si volim nastroje s vlastnostmi, ktere mi vyhovuji.

Muj nejvetsi projek je monitorovaci system pro relly se zberem dat v terenu a jejich vizualizace na dispecinku plus par dalsich funkci. Implementovano temer kompletne v Pythonu (jen intranetova cast je v PHP), je to nekolik provazanych aplikaci, ustredni je multithreadovy server skrz ktery si vsechno ostatni vymenuje data, celkem je to cca 20 tisic radku kodu (nebo bylo, pak jsem ho jeste rozsiroval, a kolik radku ma ktery muj program mi prislo zajimave kdysi). V PHP mam pak implemntovany jeden informacni a jeden evidencni server. Ten evidencni ma cca 15 tisic radku kodu. Ten informacni je tusim vetsi, stale ho rozsiruji, ale kolik radku kodu ma netusim.

Staticka typova kontrola mi opravdu nechybi. Ale zato mam rad kvalitni reporty o chybach, treba pro Python mam toto: http://wraith.iglu.cz/python/ukazky-vyjimky.php Pro PHP mam slozitejsi a propracovanejsi system, ve kterem sbiram klicove informace o chodu programu a v pripade chyby mam pak k dispozici ulozenu vcelku komplexni informaci.