výběr konkrétní metody podle typu `self` je vlastně taky single dispatch že? Jaký má @singledispatch dopad v praxi? Napadá mě, že dokáže zapisovat dohromady stejnou funkcionalitu na stejné místo kódu. To ten "objektový" single dispatch neumí, tam je to rozházené po různých classách..
Jo ono je single dispatch vlastně "ortogonální" k dispatchi, kterej přichází s OOP. U OOP (toho klasického v Pythonu) jde o vazbu data:kód (a tedy kód je "rozházený" po třídách), u @singledispatch je typicky vazba kód:data (ty funkce bývají na jednom místě, ale nemusí být).
PS: osobně preferuji spíše funkcionální přístup a tedy single dispatch, ale záleží na struktuře projektu.
Jestli jsem to správně pochopil, tak zajímavé/edukativní by to bylo s převodem metod na operátory. Něco jako definovat "plus" k objektu dané třídy různě, protože má jiný význam, pokud k tomu objektu chceme přidat ten či jiný objekt.
školometsky by to bylo něco jako pseudokód:
class mujInt: def add(self, int) -> int @singledispatch.add def _(self, float) -> float @singledispatch.add def _(self, Complex) -> Complex
Ale určitě by šlo vymyslet nějaký nápaditější příklad typu:
class ModelLEGO: def add(self, KostkaLEGO) -> ModelLEGO @singledispatch.add def _(self, MladsiBratr) -> HromadaLEGO
Pochopil jsem to správně?
30. 4. 2026, 22:11 editováno autorem komentáře
Pracuji v Julii (zadne OOP) a multiple dispatch se mi libi. Prikladem je typ Measurement, coz je cislo ± cislo (stredni hodnota ± smerodatna odchylka). Pomoci multiple dispatch je nadefinovano co dela plus, minus, odmocnina atd. s takovymi typy a ve vysledku mam stejny kod pro bezne cisla i pro tyto s nejistotou. Uzitecne napr. pro Monte Carlo.
Off-topic: zacinam mit pochyby, jestli ma vyznam delat v Julii, kdyz Python ma dnes podporu pro typy a funkcionalni programovani.
Argument pro Julii je rychlost a statické datové typy ne? Python má jen hint, vevnitř je to stále dynamické.
Staticke datove typy ano, ale ta rychlost se minimalne u me nepotvrdila. Kdyz v Pythonu pouziju optimalizovane knihovny je to taky rychle a Julia ma nevyhodu dlouhe kompilace, tzv. time-to-first-plot. Treba pro nejake crazy HPC aplikace kde se neco pocita na klastru 2 tydny se to vyplati, ale to neni muj pripad.
Ja mam Julii rad, je za me mnohem prijemnejsi nez Python, ale nevim jestli vyhody prevazuji nad nevyhodami.
4. 5. 2026, 13:22 editováno autorem komentáře
Já teda Python moc nemusím - jednu věc co na něm vidím, je, že je to open source, který není navázaný na žádný korporát. To je super, a pochopitelně frčí v Linuxu. Je dobrý na skripty. Ale tady výčet končí.
Jakákoliv větší aplikace, co se bude vyvíjet dýl, než 4 týdny, tak na to patří Java a Spring.
A v případě moderního webu Node.js. A u nemoderního komunitního webu PHP.
Pokud na to nedáte Javu, tak budete z Pythonu dělat Javu a hádejte co - líp to nevymyslíte, spíše dopadnete vždycky hůře.
Java je přesně o tom, že když něco vyvijím dýl než ty 2-4 týdny, tak tam musím mít pořádek, jaký vynucuje Java. Na druhou stranu do 2 týdnů práce se může vyplatit Python.
2. 5. 2026, 09:43 editováno autorem komentáře
No záleží asi na konkrétním projektu, znalosti lidí, požadavcích na deployment atd. To, co například děláme u nás, by s Javou a Springem hodně bolelo a nejsem si ani jistý nabídkou vhodných knihoven pro Javu (ale popravdě už to pár let nesleduju).
Jinak: jak by se tedy ten dynamic multiple dispatch udělal v Javě? Asi by se to nějak ohnulo přes vzor Visitor?