Názory k článku Nástroje pro statické typové kontroly v ekosystému jazyka Python

já na tu kovarianci a kontravarianci narazil s jedním javistou z firmy, a i když mi tvrdil opak, tak podle mě to v Javě nejde rozumně udělat. "pomáhá" type erasure, ale ta ten problém spíš zakrývá. To je trošku zvláštní, když by typovej systém Javy měl být teoreticky více "sound".

[dal jsem to jako komentář, protože to s tématem článku tak úplně nesouvisí]

5. 5. 2026, 11:00 editováno autorem komentáře

pouzivame Mypy a pyright. Ty je sice nejrychlejsi, ale "bije" se s temi ostatnimi tam, kde je neco na zpusob: # pyright: ignore[reportMis­singImports] atd. (dava false negatives)

Ja uz si bez pyright neviem predstavit pracovat v Pythone. Vsetky projekty strict-by-default a CI fail ak zlyha typova kontrola. Nevravim ze staticka typova kontrola je silver bullet, ale chyti to vela veci a stale existuje moznost vyuzit "Any" ak clovek potrebuje naplno vyuzit moznosti Pythonu.

Trochu off-topic, ale fascinuje ma, ze vseobecny sentiment okolo "customer-facing" Microsoft veci je skor negativny. Naopak Microsoft Research produkuje hit za hitom (pyright, Lean, Koka, z3, TypeScript, F#, etc.).

Jednou se mě na pohovoru ptali, pro jakou firmu bych chtěl pracovat a proč a pro kterou nechtěl.
Pro SUN, protože jsou tam dobří inženýři a obchodníci.
Pro Microsoft ne, protože tam jsou obchodníci a dobří inženýři.

TypeScript je jednoznačně hit, všechny ostatní zmíněné věci jsou sporné (nerdí hračky nebo překonaný Pyright).

F# je z nejakeho duvodu dost mimo zajem. to je skoda, je to ML-like jazyk a docela pekne udelany (az na ten ekosystem okolo, mozna to je duvod nezajmu?)

Já jsem silně funkcionálně positivní, v F# jsem udělal jednu apku, vysloveně dobrovolně, iniciativně, chtěl jsem to zkusit. A nějak mi to vůbec nechutná.

Taky by šlo použít Mojo od Modularu.

Ten argument na začátku, že psát typy u malých věcí je zbytečné - s tím nesouhlasím. Ty typy se hodí úplně od začátku všude a jako vedlejší benefit je ten, že deklarace určuje viditelnost (blok) proměnné. Teď jsem hledal chybu v kódu dítěte, kde proměnná byla použita bez předchozího přiřazení - dlouhá zábava hledání jehly v kupce sena za to, že si autor ušetří deklaraci :-/ .

Autoři modernějších jazyků se snažili původně udělat lepší shell a tenhle nedostatek tam všichni zkopírovali. A teď to zachraňují a samozřejmě jenom napůl cesty, bo existující kód musí stále fungovat.

Tím napůl cesty myslím pouze statickou kontrolu. Zatímco Java bude mít u konkretních implementací se specifickým typem už specifický typ u parametrů funkce, které jsou u původní deklarace parametrizované, a pokus zavolat funkci se špatným typem padne na ClassCastException, tak Python vesele proměnnou akceptuje a pak na ni ještě volá operátory se všemi důsledky (jako třeba formátování řetězce místo zbytku po dělení).

Tenhle dynamický typovaný design není dobrý ani pro počítač, ani pro člověka.

Máš například Pydantic a nemáš zač. Že miluješ Javu není alibi pro šíření podobných bludů.

"teď jsem hledal chybu v kódu dítěte, kde proměnná byla použita bez předchozího přiřazení" - to bylo v kterém jazyce? Určitě ne v Pythonu že?

Byl to Python a spadl v runtime. Tím hledáním jsem myslel analyzovat logický smysl té proměnné a její block scope. Proto ten závěr - kompilátor to musí odtušit, člověk taky a jako bonus přicházíme o sémantickou kontrolu kódu - absence deklarace a typů opravdu nepomáhá nikomu s výjimkou write-once-and-forget, což se hodí maximálně na příkazovou řádku v shell.

PS: Tím neříkám, že je to samospasitelné nebo že C++ nebo Java jsou nejlepší (odpověď na další komentář). Perl třeba zavedl "use strict", který vyžadoval aspoň deklaraci - ale typy stále chyběly (ten je spíš celkově postavený na principu, že typ by měl být záměrně neznámý a příliš flexibilní).

Jenže logický smysl proměnné je věc, kterou žádný jazyk nevyřeší. Proměnná, u které hrozí, že se použije před přiřazením, se odhalí snadno statickou analýzou (doporučuju primárně používat Ruff). Statická analýza do značné míry nahrazuje v Pythonu absenci striktnosti kompilátoru, kterou nabízí třeba Rust a další jazyky. Typové anotace dávají statické analýze větší přesnost, nicméně lintery toho odhalí dost i bez nich.

Možná si nerozumíme. Python v tomto případě přece žádné "use strict" nepotřebuje, protože od začátku vyžaduje vytvoření proměnné před jejím použitím a jako poslední instance na to upozorní interpret.

Tj. nenastane situace, že by třeba tu proměnnou při prvním čtení magicky naplnil nulou/False/práz­dným řetězcem nebo třeba dummy Objectem.

Ten problém s použitím proměnné před deklarací najde v Pythonu každý nástroj k tomu určený (Ruff, pylint, pyright, mypy, ty - a jakýkoli editor s pylsp to vysvítí). V případě, že proměnnou jen čtete, budou mít všechny rozumné jazyky naprosto stejný problém (tedy asi kromě BASICu, který si vesele proměnnou vytvoří na pozadí :-)

"... najde každý nástroj k tomu určený - pylint, mypy, ..."

To je smysl mého původního příspěvku - to rozhodnutí na začátku, že deklarace a typové informace nejsou potřeba, bylo jednoduše mylné a teď dohánějí hackováním přes externí nástroj. A dohánějí to všechny populárnější jazyky, nejenom Python.

Ještě jenom příklad na deklaraci (silně zjednodušený - pomíjím, že se to dá napsat přes ternary, využití je jednoduché, atd):

# více kódu tady
while something:
    # více kódu tady
    if count < 5:
        level = "low"
    else:
        level = "high"
    print("Number of people is " + level)
    # více kódu tady
# více kódu tady

Java (obecně většina kompilovaných jazyků) nebo Perl mi takový kód nezkompilují, pokud nebudu mít deklaraci na správném místě - a tam mi jako člověku rovnou říká scope a smysl. U Python musím projít kód a podmínky a pochopit, jaký bude asi scope té proměnné. A jsme zpátky u: "Ten argument na začátku, že psát typy u malých věcí je zbytečné - s tím nesouhlasím."

7. 5. 2026, 16:37 editováno autorem komentáře

No zrovna Java má to taky dost problémů s přilepenými generiky. A proto třeba nechápu Go, že to nemělo od začátku (co si budu nalhávat, já ten jazyk nechápu vůbec).

děkuju za článek, hlavně za edukativní vložku s variacemi. hned mám zase o kousek jasněji.
(marně hledám nějaké rozřešení problému, kdy bych buď spammoval pod každým článkem co se mi líbil, nebo nikdy nedal žádnou zpětnou. vlastně jsem ještě nezaznamenal Tišníkův článek, co by chválu nezasloužil)