Názory k článku Algebraické datové typy v Pythonu
-
Díky za článek, zajímavé okénko, i když ta terminologie mne mate. Například na začátku jsou zmíněny operátory and a or - ale v textu jsem nic co by bylo jako "typový and" nenašel - aspoň ne ve smyslu průniku, jak mi to přijde přirozené a je třeba v Lispu - např
(and (integer 0 3) (satisfies evenp))
je 0 nebo 2. Tím operátorem and se tedy myslí některý ze součinových typů (record, tuple)? Na druhou stranu používat and pro v podstatě kartézský součin mi nepřijde čisté.
A proč vlastně to sjednocení musí být disjunktní? Aby v tom match case nezáleželo na pořadí klauzulí?
-
Pavel TišnovskýZlatý podporovatel"typový and" je implicitní u záznamů (tedy v Pythonu u n-tic, pojmenovaných n-tic a datových tříd). Vlastně se tam nepřímo říká něco ve stylu: typ User je složen položky typu Name A SOUČASNĚ z typu Surname atd. Lepší je používat ten původní termín product type, ten to vystihuje lépe, protože popisuje "mohutnost" výsledného typu (viz ten příklad se záznamem s několika položkami typu boolean).
Termín "and" vychází z Curryho–Howardova isomorfismu z teorie typů. To jsem mohl uvést, ale zase jsem ten článek nechtěl udělat "akademickým". Pořád si myslím, že teorie typových systémů je důležitá (ale nedokončená :-), na druhou stranu to může lidi strašit, i když v praxi je to třeba v Pythonu vlastně strašně jednoduché.
-
Pavel TišnovskýZlatý podporovatel
re disjunktní - vlastně ano, i z tohoto důvodu. on ten flow musí být dost jednodznačný, aby to typovému systému pomohlo s analýzou kódu
-
Pavel TišnovskýZlatý podporovatel
ano, ty typy v Elmu jsou taky algebraické
Ovšem Elm a Python jsou z pohledu zápisu zdrojáků na opačné straně spektra:
- u Pythonu se zadávají type hinty u parametrů a návratových hodnot
- Elm má typovou inferenci a odvozuje typy od konkrétních hodnotOsobně mi vyhovuje spíš ten přístup ML jazyků, ale co už, musíme pracovat s nedokonalými nástroji :-)
-
Pavel TišnovskýZlatý podporovatel
Používals někdy ML jazyky v profi praxi? Myslím, jestli jsou takové pozice. Vím, že Jane Street dost používá OCaml a čekal jsem, že se rozšíří aspoň F#, ale nějak to pořád ne a ne dojít do mainstreamu :/ (Haskell řadím do stejné skupiny, což možná někoho naštve)
-
radekmStříbrný podporovatel
čekal jsem, že se rozšíří aspoň F#, ale nějak to pořád ne a ne dojít do mainstreamu
Upřímně vcelku pochybuji, že F# někdy dojde do mainstreamu. Posledních pár let mám pocit, že spíš kráčí opačným směrem.
Hodně novinek ve světě .NETu z poslední doby je totiž pouze pro C#, protože závisí na generátorech zdrojového kódu nebo protože nikdo nepřemýšlel, jak se to bude používat v F#. Navíc původní tvůrce jazyka, Don Syme, už na F# nepracuje. A stávající tým pro F# dělá v pracovní době často věci jiné než F# (aspoň to jsem vydedukoval z některých příspěvků na Twitteru).
-
Pavel TišnovskýZlatý podporovatel
jo no, co se dá dělat. Ono to asi s okrajovými jazyky bude stále horší, protože LLMka poskytují kladnou zpětnou vazbu u mainstreamu. Možná to "zabetonuje" vývoj, no uvidíme (ale i podle Tiobe to vypadá, že top 10 tady s námi bude pěkně dlouho).
-
Dělal jsem a nedodělal jeden projekt v Haskellu. Obecně vzato dal mi hodně, ale už ho nepoužívám. Maximálně ke studijním účelům "jak by se toto udělalo normálně v Haskellu?"
Pokud považuješ za ML Rust, tak ten ano. Pokud ne, tak ne :-)
F# jsem jen prolétl, ale komunita díky C# je dost nevděčná, takže tam se nic nerozjelo. A Microsoftímu světu se spíše vyhejbám
Kam směřuješ tou otázkou?
-
Pavel TišnovskýZlatý podporovatel
Díky
Rust tam asi taky spadá svým typovým systémem atd.
"Kam směřuješ tou otázkou?" - jen mě zajímá, jestli se tím dá uživit. A osobně si také myslím, že Haskell a spol. dokážou zlepšit myšlení programátora, který potom používá i jiný jazyk.
-
radekmStříbrný podporovatel
jen mě zajímá, jestli se tím dá uživit
Já se živím F#, ale moc velký zájem o to není. Nicméně, když řeknu, že za tím strojí MS, tak zákazníkům nevadí, když se to použije.
-
Navážu na to, co už psal @radekm.
Moje zkušenost je taková, že klienty jazyk až tak moc nezajímá. Klient má buď firmu, a vytvoří tým vývojářů. Nebo si najme vývojářský tým. Takže to všechno stojí a padá na tom vývojářským týmu. Pokud bude banda vývojářů v Haskellu, kteří nejsou idealisti ale jsou schopni splnit zadání klienta, tak...
S tím souvisí můj dojem, že prostě vývojáři jsou tak trochu hloupí (omlouvám se za aroganci). A spousta těch chytřejších vývojářů položí řemeslo na hřebík a jdou dělat business. Ve výsledku místo toho, aby použili chytřejší jazyky, tak si naberou pod sebe hloupější vývojáře a ti chytřejší jazyky nedávají. Proto stále existuje poptávka po C#, PHP, Javě, C++.
Haskell jsem opustil protože Rust. Rust je výkonější, čitelnější, přátelštější, cargo je lepší jak cabal, v Rustu se dá tak trochu prasit, což někdy potřebuješ. Haskell je čistější, logičtější a správnější. Ale Rust si z něho vyzobal to nejlepší a je strašně, strašně moc dostatečně dobrý.
Hmm, jsem už hodně off-topic? :-)
-
Pavel TišnovskýZlatý podporovatel
tyjo to je divné, protože tuple se chová jako immutable seznam. Jsou v něm skutečně uloženy numerické hodnoty?
Pokud je to něco jako x=("foo", 42, "bar"), tak normálně x[1] vrátí 42 jako číslo:
>>> x=("foo", 42, "bar")
>>> x[1]
42
>>> type(x[1])
<class 'int'>Ony tam spíš budou řetězce nebo tak něco...
-
Ne, to je mojí neschopností, nějaká snad fyzikální knihovna, nebo možná něco s canbus komunikací nebo xml mi myslím vyhazovala výstupy v nějakým (pro mě relativně komplikovaným) tuple, když jsem to vydoloval, vykopíroval do nový proměnný a chtěl s tim pracovat tak to prostě nešlo, nejspíš to byly ty řetězce...
Od tý doby to prostě nemám rád, strávil jsem s tím několik hodin a protože jsem tu knihovnu neznal, neznal jsem ani ty výstupy, v dokumentaci jsem se nic nedočet, takže sem to ladil pokus-omyl.... -
Tak to jde odzkouset primo v interpretru, co ta Tuple obsahuje:
Tuple = (2, 4, (8, 7, 30), 6, 220, 10, 77, 54) for item in Tuple: print(item, type(item))Vypise:
2 <class 'int'>
4 <class 'int'>
(8, 7, 30) <class 'tuple'>
6 <class 'int'>
220 <class 'int'>
10 <class 'int'>
77 <class 'int'>
54 <class 'int'>Takze sahnes po Tuple[2] coz je dalsi n-tice. A v ni je prvek 30, kterej te zajima, taky na pozici 2, takze:
Tuple[2][2]Vyhodi:
30 -
Pavel TišnovskýZlatý podporovatel
OT: já nemám rád poštu, protože mi nosí papírky "Nezastižen", i když pracuji z domu :-)
-
Pavel TišnovskýZlatý podporovatel
v Pythonu vede k chybám (hlavně u lidí, co na tento jazyk přecházejí), jak se zapisuje n-tice s jedním prvkem. Úvahy jsou asi následující:
- n-tice se třemi prvky se zapisuje jako (1, 2, 3)
- n-tice se dvěma prvky (dvojice) se zapisuje jako (1, 2)
- a tedy n-tice s jedním prvkem se zapisuje jako (1)jenže to není pravda, to poslední je jen výraz s konstantou v závorce, správně je (1, )
(Vlastně mi vypadl unit type, ale to je ještě zamotanější :-)
Ono to nevadí do chvíle, než se n-tice používají jako immutable seznamy
-
Pavel TišnovskýZlatý podporovatel
jj já vím, jen jsem psal, jak to vidí vývojáři, kteří na Python přechází. Jdou na https://www.w3schools.com/python/python_tuples.asp (například) a tam čtou "Tuples are written with round brackets". Nebo - což asi udělají dnes častěji - se zeptají LLMka (se správně nastaveným system promptem etc.):
"how to write tuple?"
"In Python, a tuple is created by placing comma-separated values inside parentheses (). Here is an example of how to write a tuple: my_tuple = (1, 2, 3, 4, 5) Tuples are immutable, which means their elements cannot be changed after creation."
provider:OpenAI
model: gpt-4[ale to se dostáváme trošku jinam - k tomu, že každá blbost z LLM už bude nadlouho chápána jako ta jediná pravda, protože je samopotvrzující se]
10. 5. 2025, 12:02 editováno autorem komentáře
-
To ano, v dnešní době je velmi snadné podlehnout dezinformacím a je proto potřeba pečlivě vybírat kvalitní zdroje, proto také sleduji Vaši práci ;)
Osobně jsem se to naučil od Freda Baptiste, ale třeba tutorial na python.org to má také korektně:
```
A tuple consists of a number of values separated by commas, for instance:
t = 12345, 54321, 'hello!'
```
V "oficiálním" popisu data modelu tamtéž je zmíněn i ten "problematický" singleton.Pro zajímavost mě gpt-4 s kustomizací https://chatgpt.com/g/g-cKXjWStaE-python odpověl vcelku korektně:
` Create a Tuple`
```
1. With parentheses:
my_tuple = (1, 2, 3)
2. Without parentheses (comma makes the tuple):
another_tuple = 1, 2, 3
3. Singleton tuple (important syntax quirk):
not_a_tuple = (1) # This is just an integer
singleton = (1,) # This is a tuple with one element
4. Using the tuple() constructor:
tuple_from_list = tuple([1, 2, 3])
```
díky kc10. 5. 2025, 20:35 editováno autorem komentáře
-
Pořád to je nekonzistentní, pokud by udělali povinnou trailing comma, bylo by to konzistentní pro všechny délky tuple. Ale ne, je to pořád jenom pro jednočlennou n-tici. A trailing comma je povolená a některé formátovače (Ruff) podle ní mohou měnit formátování - prostě zmatek.
Nakonec dojdeme k tomu, že řešením jsou stejně typové anotace - stejně jako v jiných jazycích. Duck typing je přinejmenším kontroverzní věc.
