Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: pyN00b 24. 03. 2016, 01:56:57

Název: Python - dobré rady a praktiky
Přispěvatel: pyN00b 24. 03. 2016, 01:56:57
Ahoj,
Zatim jsem v zivote napsal tak 5-10k radku pythoniho kodu, vsechno mensi kusy kodu, ktere neco malo resily. Ceka me spoluprace na vetsim / velkem projektu v pythonu a chtel by si nastudovat nejake doporucene praktiky, jak je co doporucene resit a co je vylozene spatny zpusob.

Mam tedy otazku na zkusenejsi programatory v Pythonu. Mohli by jste mi doporucit knizku nebo internetovy zdroj o dobrych praktikach a pristupech, jak v Pythonu rozume programovat? Tech zdroju na internetu je hrozne moc, a nevim, ktery je kvalitni.

Aktualne procitam http://shop.oreilly.com/product/0636920028963.do (http://shop.oreilly.com/product/0636920028963.do). Slibuju si, ze se seznamim, jak efektivne pouzivat datove struktury. Chtel bych neco na tema OOP (spoustu let programuju v Jave, ktera ma OOP pojate docela jinak nez v py) nebo obecne praktiky...

Diky za rady! :)
Název: Re:python - dobre rady & praktiky
Přispěvatel: mlaďas 24. 03. 2016, 02:03:33
Tak třeba špatná praktika je používat skriptovací jazyk na velké projekty. V Pythonu se rozumě moc dělat nedá, protože je vhodný tak na malé skriptíky.

OOP je samozřejmě úplně stejné jako v Javě, jen si tam půlku věcí děláš sám a ještě můžeš řešit metatřídy, což bys vůbec u větších projektů neměl :D

Fakt nedoporučuju, ale zjistíš to sám...
Název: Re:python - dobre rady & praktiky
Přispěvatel: pynoob 24. 03. 2016, 02:48:47
nastupuju do nove prace, kde je projekt udelany v pythonu. ja s tim nic neudelam. ;-)
Název: Re:python - dobre rady & praktiky
Přispěvatel: Ivan Nový 24. 03. 2016, 06:57:35
Důležité je pochopit toto http://blog.startifact.com/posts/older/what-is-pythonic.html a další odkazy https://www.google.cz/search?client=ubuntu&channel=fs&q=pythonic&ie=utf-8&oe=utf-8&gfe_rd=cr&ei=poHzVtCxHMiI8QfcpYaQCg
Název: Re:python - dobre rady & praktiky
Přispěvatel: Ivan Nový 24. 03. 2016, 07:05:23
Tak třeba špatná praktika je používat skriptovací jazyk na velké projekty. V Pythonu se rozumě moc dělat nedá, protože je vhodný tak na malé skriptíky.

OOP je samozřejmě úplně stejné jako v Javě, jen si tam půlku věcí děláš sám a ještě můžeš řešit metatřídy, což bys vůbec u větších projektů neměl :D

Fakt nedoporučuju, ale zjistíš to sám...
Tak OOP je od toho, aby i velký projekt byl malý :-))) Pokud je to jinak, tak je něco špatně s návrhem, nikoliv s jazykem. Když začínala Java, tak otloukánkem místo skriptovacích jazyků, byly jazyky postavené na VM, taky v nich prý nešlo dělat velké projekty.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 24. 03. 2016, 10:38:16
V žádném jazyku nejde dělat větší projekt pokud návrh stojí za hovno. Python je pomalej šmejd, dříve navíc i dost nekonzistentní ale od 3 už snad začali OOP brát trošičku vážněji ... v něm bych rozhodně nic velkýho nedělal. Jako ostatně asi v žádném dynamicky typovaném jazyku, to je ale jen můj názor, třeba mi někdo dokáže že není nic lepšího než dynamickej jazyk.
Název: Re:python - dobre rady & praktiky
Přispěvatel: Viky 24. 03. 2016, 11:00:17
Tak třeba špatná praktika je používat skriptovací jazyk na velké projekty. V Pythonu se rozumě moc dělat nedá, protože je vhodný tak na malé skriptíky.
Blbost. Proč by to tak mělo být? Protože to někdo řekl?

OOP je samozřejmě úplně stejné jako v Javě, jen si tam půlku věcí děláš sám a ještě můžeš řešit metatřídy, což bys vůbec u větších projektů neměl :D
OOP v Pythonu je samozřejmě úplně jiné než v Javě. Ne, že by se nedalo používat stejně, ale byla by to škoda, protože Java je takový nedotažený objektový jazyk – sice o třídu lepší než C++, ale pořád o třídu horší než třeba Ruby nebo Objective C. Při OOP v Pythonu doporučuji spíše si osvojit praktiky používané v těch dvou posledně jmenovaných jazycích nežli v Javě.

Fakt nedoporučuju, ale zjistíš to sám...
Když se to dobře navrhne, ušetří se díky Pythonu spousta práce oproti jiným řešením. Záleží samozřejmě na konkrétním případu. Pokud to někdo neumí dobře navrhnout, např. kvůli neznalosti Pythonu nebo kvůli celkové vlastní neschopnosti (což je v současnosti v IT asi nejběžnější případ, od té doby, co se sem cpe každý, kdo má do p… díru), není to chyba Pythonu. Ovšem takový člověk by měl asi popřemýšlet o jiné profesi, třeba nějaké manuální, na niž mentálně stačí.
Název: Re:python - dobre rady & praktiky
Přispěvatel: čumil 24. 03. 2016, 11:35:43
Tak třeba špatná praktika je používat skriptovací jazyk na velké projekty. V Pythonu se rozumě moc dělat nedá, protože je vhodný tak na malé skriptíky.
Blbost. Proč by to tak mělo být? Protože to někdo řekl?

OOP je samozřejmě úplně stejné jako v Javě, jen si tam půlku věcí děláš sám a ještě můžeš řešit metatřídy, což bys vůbec u větších projektů neměl :D
OOP v Pythonu je samozřejmě úplně jiné než v Javě. Ne, že by se nedalo používat stejně, ale byla by to škoda, protože Java je takový nedotažený objektový jazyk – sice o třídu lepší než C++, ale pořád o třídu horší než třeba Ruby nebo Objective C. Při OOP v Pythonu doporučuji spíše si osvojit praktiky používané v těch dvou posledně jmenovaných jazycích nežli v Javě.

Fakt nedoporučuju, ale zjistíš to sám...
Když se to dobře navrhne, ušetří se díky Pythonu spousta práce oproti jiným řešením. Záleží samozřejmě na konkrétním případu. Pokud to někdo neumí dobře navrhnout, např. kvůli neznalosti Pythonu nebo kvůli celkové vlastní neschopnosti (což je v současnosti v IT asi nejběžnější případ, od té doby, co se sem cpe každý, kdo má do p… díru), není to chyba Pythonu. Ovšem takový člověk by měl asi popřemýšlet o jiné profesi, třeba nějaké manuální, na niž mentálně stačí.
Všechny OOP jazyky dneška sou nedotažené, i ta tvoje milovaná kobra je nedotažená. A všechny sou nedotažený úplně stejně. Tečka. Smalltalk. Tečka.
Název: Re:python - dobre rady & praktiky
Přispěvatel: TiB 24. 03. 2016, 12:17:37
Co je tohle za blbost  ::) Že se v pythonu nedá nic dělat. Ufff.. 

Tak třeba špatná praktika je používat skriptovací jazyk na velké projekty. V Pythonu se rozumě moc dělat nedá, protože je vhodný tak na malé skriptíky.

OOP je samozřejmě úplně stejné jako v Javě, jen si tam půlku věcí děláš sám a ještě můžeš řešit metatřídy, což bys vůbec u větších projektů neměl :D

Fakt nedoporučuju, ale zjistíš to sám...
Název: Re:python - dobre rady & praktiky
Přispěvatel: Viky 24. 03. 2016, 13:44:58
Všechny OOP jazyky dneška sou nedotažené, i ta tvoje milovaná kobra je nedotažená. A všechny sou nedotažený úplně stejně. Tečka. Smalltalk. Tečka.
Někomu holt stačí říct málo, aby hned bylo jasné, že o problematice, k níž se vyjadřuje, ví prd. A čím jednoznačnější, sebejistější a více generalizující názory, tím větší prd o tom obvykle ví.
Název: Re:python - dobre rady & praktiky
Přispěvatel: mlaďas 24. 03. 2016, 13:53:16
Tak třeba špatná praktika je používat skriptovací jazyk na velké projekty. V Pythonu se rozumě moc dělat nedá, protože je vhodný tak na malé skriptíky.
Blbost. Proč by to tak mělo být? Protože to někdo řekl?

OOP je samozřejmě úplně stejné jako v Javě, jen si tam půlku věcí děláš sám a ještě můžeš řešit metatřídy, což bys vůbec u větších projektů neměl :D
OOP v Pythonu je samozřejmě úplně jiné než v Javě. Ne, že by se nedalo používat stejně, ale byla by to škoda, protože Java je takový nedotažený objektový jazyk – sice o třídu lepší než C++, ale pořád o třídu horší než třeba Ruby nebo Objective C. Při OOP v Pythonu doporučuji spíše si osvojit praktiky používané v těch dvou posledně jmenovaných jazycích nežli v Javě.

Fakt nedoporučuju, ale zjistíš to sám...
Když se to dobře navrhne, ušetří se díky Pythonu spousta práce oproti jiným řešením. Záleží samozřejmě na konkrétním případu. Pokud to někdo neumí dobře navrhnout, např. kvůli neznalosti Pythonu nebo kvůli celkové vlastní neschopnosti (což je v současnosti v IT asi nejběžnější případ, od té doby, co se sem cpe každý, kdo má do p… díru), není to chyba Pythonu. Ovšem takový člověk by měl asi popřemýšlet o jiné profesi, třeba nějaké manuální, na niž mentálně stačí.

To já nevim, proč je Python skriptovací jazyk. To se zeptej tvůrců. Taky nejdeš dělat bankovní middleware v Bashi, že jo...

Takže co tam použiju jinak než v Javě, abych si trochu pomohl a Python stál za to?

Co chceš dobře navrhovat? Všechno je vždycky dobře navržený, akorát jazyky na větší projekty mají prostě lepší podporu. Můžeš mi vysvětlit, jak se dělají úravy u dynamicky typovaných jazyků? Prostě přijde od zákazníka požadavek. Máš třeba milion řádek kódu a chceš rychle udělat nějakou ne úplně triviální změnu. Třeba ten projekt ani moc neznáš, protože prostě je to nějaký starší kousek. Chápu, že ty na to máš určitě postupy, které nikdo ještě nenašel, ale právě proto by mě to zajímalo.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: mlaďas 24. 03. 2016, 13:54:30
v něm bych rozhodně nic velkýho nedělal. Jako ostatně asi v žádném dynamicky typovaném jazyku, to je ale jen můj názor, třeba mi někdo dokáže že není nic lepšího než dynamickej jazyk.

Tak nějak, ale určitě nám to nějaký odborník vysvětlí. Třeba že je vlastně lepší najít chyby až v produci.
Název: Re:python - dobre rady & praktiky
Přispěvatel: Viky 24. 03. 2016, 14:55:49
To já nevim, proč je Python skriptovací jazyk. To se zeptej tvůrců. Taky nejdeš dělat bankovní middleware v Bashi, že jo...
A co z toho jako plyne? Logicky mi to zdůvodni.

Takže co tam použiju jinak než v Javě, abych si trochu pomohl a Python stál za to?
Je to dost odlišný přístup, hlavně z toho důvodu, že je to dynamicky typovaný jazyk. Pokud budeš postupovat stejně jako u Javy, tak částečně chápu to rozčarování nad výsledkem. Ale to není chyba jazyka, a už vůbec ne dynamického typování. To je nekompetentnost vývojáře, který ten rozdíl nemá zažitý a neví, že hřebíky se zatloukají kladivem, zatímco šrouby se šroubují šroubovákem – ačkoli obojí slouží ke spojování dílů a vypadá to docela podobně – kovová tyčinka s hlavičkou. Proto když se někdo vyjádří, že mezi javským a pythoním přístupem k OOP není rozdíl, tak je to asi obdobně, jako by se řemeslník vyjádřil, že mezi šroubem a hřebíkem není vlastně vůbec žádný principiální rozdíl, akorát šrouby jsou na nic, protože se oproti hřebíkům fakt strašně špatně zatloukají. Takový člověk je zkrátka úplně mimo.
Rozdílnost přístupu je vidět třeba při srovnání javské knihovny vs. COCOA. Prostě využívají se spíše např. proxy objekty, kompozice, swizzling a jiné „volnější” techniky na úkor dědění a jiných „rigidnějších” přístupů (nemyšleno peiorativně, prostě je to odlišný přístup).

Co chceš dobře navrhovat? Všechno je vždycky dobře navržený, akorát jazyky na větší projekty mají prostě lepší podporu.
Co je to jazyk pro větší projekt? Jak je definován? Jak se liší od jazyka pro menší projekt? Podporu v čem/čeho přesně?

Můžeš mi vysvětlit, jak se dělají úravy u dynamicky typovaných jazyků?
No jo, tak už jsme doma. Stačilo jen napsat nechápu/nesedla mi filosofie dynamicky typovaných jazyků a její odlišnost od přístupu, na nějž jsem zvyklý.
Název: Re:python - dobre rady & praktiky
Přispěvatel: čumil 24. 03. 2016, 15:00:31
Všechny OOP jazyky dneška sou nedotažené, i ta tvoje milovaná kobra je nedotažená. A všechny sou nedotažený úplně stejně. Tečka. Smalltalk. Tečka.
Někomu holt stačí říct málo, aby hned bylo jasné, že o problematice, k níž se vyjadřuje, ví prd. A čím jednoznačnější, sebejistější a více generalizující názory, tím větší prd o tom obvykle ví.
Ámen, je úžasný jak některý tvrzení udělá backfire. Skutečně o OOP nic nevíš vzhledem k předchozím tvrzením.
Název: Re:python - dobre rady & praktiky
Přispěvatel: JSH 24. 03. 2016, 15:18:24
Můžeš mi vysvětlit, jak se dělají úravy u dynamicky typovaných jazyků?
No jo, tak už jsme doma. Stačilo jen napsat nechápu/nesedla mi filosofie dynamicky typovaných jazyků a její odlišnost od přístupu, na nějž jsem zvyklý.
Jsem taky jeden z těch, co tu filosofii dynamicky typovaných jazyků moc nechápou. Jakým způsobem se dá fungovat s tím, že vlastně nevím vůbec nic o tom, co mi volající předá. Mám pocit, že bych měl psát unit testy i na to, jestli se moje funkce rozumně popasují s tím že místo intu dostanu string.
Jak se v Pythonu řeší, když vím že potřebuju nějaký int a nic jiného na daném místě nechci?
Název: Re:python - dobre rady & praktiky
Přispěvatel: Ondra Satai Nekola 24. 03. 2016, 15:23:43
Můžeš mi vysvětlit, jak se dělají úravy u dynamicky typovaných jazyků?
No jo, tak už jsme doma. Stačilo jen napsat nechápu/nesedla mi filosofie dynamicky typovaných jazyků a její odlišnost od přístupu, na nějž jsem zvyklý.
Jsem taky jeden z těch, co tu filosofii dynamicky typovaných jazyků moc nechápou. Jakým způsobem se dá fungovat s tím, že vlastně nevím vůbec nic o tom, co mi volající předá. Mám pocit, že bych měl psát unit testy i na to, jestli se moje funkce rozumně popasují s tím že místo intu dostanu string.
Tohle resis spis na urovni integracnich testu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: uetoyo 24. 03. 2016, 15:23:50
Co Bruce Eckel?
http://python-3-patterns-idioms-test.readthedocs.org/en/latest/PatternConcept.html
Název: Re:python - dobre rady & praktiky
Přispěvatel: zboj 24. 03. 2016, 15:32:29
Můžeš mi vysvětlit, jak se dělají úravy u dynamicky typovaných jazyků?
No jo, tak už jsme doma. Stačilo jen napsat nechápu/nesedla mi filosofie dynamicky typovaných jazyků a její odlišnost od přístupu, na nějž jsem zvyklý.
Jsem taky jeden z těch, co tu filosofii dynamicky typovaných jazyků moc nechápou. Jakým způsobem se dá fungovat s tím, že vlastně nevím vůbec nic o tom, co mi volající předá. Mám pocit, že bych měl psát unit testy i na to, jestli se moje funkce rozumně popasují s tím že místo intu dostanu string.
Jak se v Pythonu řeší, když vím že potřebuju nějaký int a nic jiného na daném místě nechci?
K Pythonu se moc vyjadřovat nemůžu, ale v takovém Objective-C se typy používají při kompilaci, i když jazyk (runtime) je plně dynamický, čímž má člověk vlastně to nejlepší z obou světů (tím ale netvrdím, že dynamické jazyky jsou lepší, jen že zmíněný problém je řešitelný).
Název: Re:python - dobre rady & praktiky
Přispěvatel: uetoyo 24. 03. 2016, 15:42:14
Citace
Jak se v Pythonu řeší, když vím že potřebuju nějaký int a nic jiného na daném místě nechci?

Prostě otestuješ jestli je to `int`, když už to takhle potřebuješ.

Lepší je se ale ptát co ten `int` představuje -- jak ho interpretuješ;  pak ti stačí, když ti podstrčím něco, co ti je schopné dát požadovanou celočíselnou hodnotu; ... a tak dál, a tak podobně -- *to bude zas nekonečný seriál dynamicky vs staticky typované jazyky*
Název: Re:python - dobre rady & praktiky
Přispěvatel: takynechápe 24. 03. 2016, 16:01:40
Citace
Jak se v Pythonu řeší, když vím že potřebuju nějaký int a nic jiného na daném místě nechci?

Prostě otestuješ jestli je to `int`, když už to takhle potřebuješ.

Lepší je se ale ptát co ten `int` představuje -- jak ho interpretuješ;  pak ti stačí, když ti podstrčím něco, co ti je schopné dát požadovanou celočíselnou hodnotu; ... a tak dál, a tak podobně -- *to bude zas nekonečný seriál dynamicky vs staticky typované jazyky*

A smysl toho? To je trochu jak u debilů, ne? Normálně předávám rozhraní a nezajímá mě implementace. Ty děláš to stejné, jen nikdo neví, co ti kdo předá a musíš jak blázen dávat pozor, jestli to funguje. A pokud ne, tak se to bude určitě super ladit. Vidím tam tu flexibilitu, jen nevím, k čemu by mi byla u vývoje.
Název: Re:python - dobre rady & praktiky
Přispěvatel: uetoyo 24. 03. 2016, 16:17:00
Citace
A smysl toho? To je trochu jak u debilů, ne? Normálně předávám rozhraní a nezajímá mě implementace. Ty děláš to stejné, jen nikdo neví, co ti kdo předá a musíš jak blázen dávat pozor, jestli to funguje. A pokud ne, tak se to bude určitě super ladit. Vidím tam tu flexibilitu, jen nevím, k čemu by mi byla u vývoje.

Do jisté míry máš pravdu. Jde se tedy ptát ... jestli je lepši explictní rozhraní nebo duck typing. Python samozřejmě umí zjistit jestli je typ instancí nějaké třídy ...ale...;  pokud se dostaněš na hranici, kdy ti to hází klacky pod nohy, je lepší se ho vzdát. Jen tak mimo řeč --- ten slovník máš z domova? :)

http://martinfowler.com/bliki/DynamicTyping.html
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 16:27:27
Umí ho zjistit před stuštěním? Po spuštění mi to už moc nepomůže. Ale chápu, že lepší než nic. Jaký slovník? Já si budu do dokumentace dávat, co tam vlastně chci cca za typ, místo toho abych ho jen uvedl? To ti jako přijde normální? Neni to vůbec divný a děláš 5x něco, co jinde máš hned? Jen tak abych měl představu, protože znám pár "programátorů" z dynamických jazyků a problém je v tom, že programovat neumí, ale dynamické typování si strašně chválí. Mám podezření, že jejich logika je tak děravá, že jim to ani nepřijde, že dělají nesmysly.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 16:37:13
Ok, ale třeba jednoduchý příklad. Mám metodu nazvanou cool_funkce s parametrem. Typ nevíme, protože jsme cool jako ta medota. Volá se na něm ale metoda send. Jaké další metody ten argument má? Nevíme, protože jsme cool. Ale můžeme si vyhledat všech 100 tisíc volání té metody a třeba najdeme všech 150 typů, které se tam posílají. Aha... No, nevim, asi radši zavřu VIM (VIM je přece best IDE!) a půjdu radši ven.

Nebo mi něco uniká? Jako určitě, takže se to rád dozvím, jak na to ;)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: uetoyo 24. 03. 2016, 16:45:07
Umí ho zjistit před stuštěním? Po spuštění mi to už moc nepomůže. Ale chápu, že lepší než nic. Jaký slovník? Já si budu do dokumentace dávat, co tam vlastně chci cca za typ, místo toho abych ho jen uvedl? To ti jako přijde normální? Neni to vůbec divný a děláš 5x něco, co jinde máš hned? Jen tak abych měl představu, protože znám pár "programátorů" z dynamických jazyků a problém je v tom, že programovat neumí, ale dynamické typování si strašně chválí. Mám podezření, že jejich logika je tak děravá, že jim to ani nepřijde, že dělají nesmysly.

Já si dynamické typování až tak nechválím :)  Pokud jde o uvedení typu, Python má type hints ... https://docs.python.org/3/library/typing.html; existuje http://mypy-lang.org/, od kterého se to celé odpíchlo.

V Pythonu se podle mne dá dělat pokud: dodržuješ nějaký mustr -- jako má třeba Django; nebo děláš "průzkum terénu" např. datovou analýzu, kdy nevíš co na tebe všechno ještě vypadne ... (IPython notebook).

Jinak to jde hodně rychle do kopru; Já sám bych si rozmyslel dělat velký projekt v Pythonu, ale někomu to jde (Dropbox) :)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 16:48:34
Sám vidíš, že type hinting je tam od 3. Trojka v podstatě nikde není. Nebo už jo? Takže ty roky před tím to dělali jak?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: uetoyo 24. 03. 2016, 16:48:43
Ok, ale třeba jednoduchý příklad. Mám metodu nazvanou cool_funkce s parametrem. Typ nevíme, protože jsme cool jako ta medota. Volá se na něm ale metoda send. Jaké další metody ten argument má? Nevíme, protože jsme cool. Ale můžeme si vyhledat všech 100 tisíc volání té metody a třeba najdeme všech 150 typů, které se tam posílají. Aha... No, nevim, asi radši zavřu VIM (VIM je přece best IDE!) a půjdu radši ven.

Nebo mi něco uniká? Jako určitě, takže se to rád dozvím, jak na to ;)

Ten typ bude v nějakém modulu, bude mít nějaký název? Možná tě špatně chápu ... jinak znáš PyDev?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: uetoyo 24. 03. 2016, 16:52:13
Sám vidíš, že type hinting je tam od 3. Trojka v podstatě nikde není. Nebo už jo? Takže ty roky před tím to dělali jak?

Promiň, já píšu jen ve verzi 3 a tady nemohu nic dodat;
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 16:53:38
Asi v nějakém modulu bude a název také bude mít. Těch názvu bude mít dokonce 15, protože si tam můžu posílat cokoli. Pydev jsem moc nezkoumal, protože to nevypadalo úplně dobře a ještě je to na Eclipse, což je nejhorší prostředí pro Javu. Na Python jsem vždy používal Pycharm.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: alex 24. 03. 2016, 18:09:27
Umí ho zjistit před stuštěním? Po spuštění mi to už moc nepomůže. Ale chápu, že lepší než nic. Jaký slovník? Já si budu do dokumentace dávat, co tam vlastně chci cca za typ, místo toho abych ho jen uvedl? To ti jako přijde normální? Neni to vůbec divný a děláš 5x něco, co jinde máš hned? Jen tak abych měl představu, protože znám pár "programátorů" z dynamických jazyků a problém je v tom, že programovat neumí, ale dynamické typování si strašně chválí. Mám podezření, že jejich logika je tak děravá, že jim to ani nepřijde, že dělají nesmysly.

Já si dynamické typování až tak nechválím :)  Pokud jde o uvedení typu, Python má type hints ... https://docs.python.org/3/library/typing.html; existuje http://mypy-lang.org/, od kterého se to celé odpíchlo.

V Pythonu se podle mne dá dělat pokud: dodržuješ nějaký mustr -- jako má třeba Django; nebo děláš "průzkum terénu" např. datovou analýzu, kdy nevíš co na tebe všechno ještě vypadne ... (IPython notebook).

Jinak to jde hodně rychle do kopru; Já sám bych si rozmyslel dělat velký projekt v Pythonu, ale někomu to jde (Dropbox) :)
Proč byste něco zjišťoval,
try:
     {block}
except ValueError:
     {block}

a dynamický jazyk si konverze udělá sám, je-li parametrem objekt, stačí, když vyhoví požadavkům metody jeho rozhraní. To může být výhoda, potřebujete-li aplikaci rozšiřovat. Stačí ohlídat rozhraní, popřípadě změnu provedete v definici toho objektu, který do metody vkládáte na jednom místě. U staticky typovaného jazyka musíte typy měnit všude v deklaracích, chcete-li aplikaci rozšířit, v extrémním případě, nepoužíváte-li nějaký pattern, který v podstatě za cenu větší režie systému přidává "dynamické" vlastnosti do statického jazyka.

A pokud je metoda použita na tisících míst, máte špatně návrh aplikace. Máte-li v aplikaci 1000 různých typů dokumentů, tak například metodu tisk u adresy použijete jen dvakrát, protože například dodací_list dědí tuto metodu z dokumentu a pak dokument->tisk ten volá adresa_dodavatele->tisk a adresa_odesílatele->tisk a jen ty v celé aplikaci volají adresa->tisk. Tedy volání je v celé aplikaci pro 1000 různých typů dokumentů jen 2x. Maximálně 4x, protože na žádném dokumentu nejsou více jak 4 různé poštovní adresy. A to je cool ne?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 18:16:27
Stačí ohlídat rozhraní, popřípadě změnu provedete v definici toho objektu, který do metody vkládáte na jednom místě. U staticky typovaného jazyka musíte typy měnit všude v deklaracích, chcete-li aplikaci rozšířit,

A to je cool ne?

To se právě dělá automaticky pomocí IDE, že jo. Hlavně máš často u typů právě jen rozhraní, takže změníš to. Já vlastně zapomněl, že Python rozhraní nepotřebuje, tak všude dáš prostě nadtyp :D To asi ne, že jo.

No, nevím...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 24. 03. 2016, 18:21:04
Trošku se musím dynamického typování zastat. Upřímně, já se aktuálně dynamicky typovaným jazykem živím ...

Napřed aby bylo jasno, dynamické typování je pro mne osobně osina v zadeki. A asi i pro mnoho dalších. Má tunu nevýhod, jako třeba, nikdy nevíš, kdy se ti appka kompletně posere, protože někde uděláš drobnou typovou změnu a ta ti nepozorovaně doplave až do středu systému a tam ti vyletí v ohňostroji exceptions s úplně nahovno stack trace protože obsahuje jen vnitřnosti frameworku který používáš ...

ALE. Dynamické typování je neskutečně silné v jednom. Dělá ze statických, mrtvých systému živé systémy. V kvalitním dynamickém jazyce (platformě přesněji) si můžeš otevřít inspektora do appky, proklikat se jednotlivejma objektama, prohlídnout si jejich interface popřípadě je za běhu upravit. To je neskutečná síla. To že se při těhle úpravách člověk velmi snadno střelí do nohy je jiná...

Můžeš existující systémy zevnitř upravit (monkey patching) či jinak přiohnout podle potřeby.

Dynamické typování je nezbytné pro skutečné OOP postavené na posílání zpráv (nee prosím, opravdu OOP není volání funkcí ve struktuře se skrytým parametrem this ...). V živém systému, totiž nikdy nemůžeš vědět co ti konkrétně přijde a jednotlivý objekty se musí rozumně popasovat s širokou škálou inputů (jako skutečné živé organismy).

To že je to ve výsledku pomalí až běda, při blbým návrhu zabugovaný až běda, je ovšem jiná ...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 18:26:56
Tyhle dynamický změny se dělají běžně u i staticky typovaných jazyků, ne? Ne že bys na nich postavil program stejně jako na monkey patchingu, ale problém to technicky nebude. Nebo co je v tom za problém?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: alex 24. 03. 2016, 18:30:09
Stačí ohlídat rozhraní, popřípadě změnu provedete v definici toho objektu, který do metody vkládáte na jednom místě. U staticky typovaného jazyka musíte typy měnit všude v deklaracích, chcete-li aplikaci rozšířit,

A to je cool ne?

To se právě dělá automaticky pomocí IDE, že jo. Hlavně máš často u typů právě jen rozhraní, takže změníš to. Já vlastně zapomněl, že Python rozhraní nepotřebuje, tak všude dáš prostě nadtyp :D To asi ne, že jo.

No, nevím...
Spoléhat na IDE je prasárna stejná jako Copy a Paste. Rozhraní ve smyslu třída argumentu metody má metodu, která se v dané metodě volá :-) K tomu žádný typ nepotřebujete. Odpovídá to taky více realitě, kterou modelujete, dveře má auto i dům, a napasovat je do jednoho typu by nebylo moc šťastné, tím vám právě vznikají nadobjekty. V Pythonu byste si nadeklaroval třídy třeba takto:
class House(building, entrance): pass
class Car(vehicle, entrance): pass
class entrance(object): def open_door(): pass;  def close_door(): pass
nebo totéž můžete provést skládáním objektů parametry v metodách __init__
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 18:36:21
Chlape, viděl si někdy větší programy? :D To přijde problém v programu, který si nikdy neviděl a musíš ho opravit. Ne si tam hrát s nějakými nesmysly.

Jaký nadobjekty? Ty máš entrance, ne? Normálně máš rozhraní s open a close. Víc tě nezajímá. Možná jsem pomalejší, ale fakt nechápu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: alex 24. 03. 2016, 18:48:53
Chlape, viděl si někdy větší programy? :D To přijde problém v programu, který si nikdy neviděl a musíš ho opravit. Ne si tam hrát s nějakými nesmysly.

Jaký nadobjekty? Ty máš entrance, ne? Normálně máš rozhraní s open a close. Víc tě nezajímá. Možná jsem pomalejší, ale fakt nechápu.
Tak samozřejmě, časem se systémy zanesou a udržují se jen těžko a není pak příliš velký rozdíl mezi špatným a dobrým návrhem, ovšem když si někdo nevyhrál na začátku, tak se ten systém zanese mnohem dříve :-)))
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 18:55:45
Ok, Kite, tak dík za info a už chápu, kdo používá Python.
Název: Re:python - dobre rady & praktiky
Přispěvatel: Kit 24. 03. 2016, 19:05:51
Jak se v Pythonu řeší, když vím že potřebuju nějaký int a nic jiného na daném místě nechci?

Úplně stejně, jako v ostatních jazycích, když metoda požaduje jako vstupní parametr třeba číslo měsíce (1..12) a někdo do ní chce narvat třeba 42. Má na to třeba Java datový typ? Nemá. Použiješ int a ošetříš si to vlastním kódem.

V Pythonu se to dá ošetřit pomocí dekorátoru.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 24. 03. 2016, 19:08:43
Tyhle dynamický změny se dělají běžně u i staticky typovaných jazyků, ne? Ne že bys na nich postavil program stejně jako na monkey patchingu, ale problém to technicky nebude. Nebo co je v tom za problém?
V c++/Jave/etc... si mužeš otevřít inspektora a prohrabat se objekty v běžícím systému + modifikovat ho? Ne, není to živá platforma.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 19:10:59
Jak se v Pythonu řeší, když vím že potřebuju nějaký int a nic jiného na daném místě nechci?

Úplně stejně, jako v ostatních jazycích, když metoda požaduje jako vstupní parametr třeba číslo měsíce (1..12) a někdo do ní chce narvat třeba 42. Má na to třeba Java datový typ? Nemá. Použiješ int a ošetříš si to vlastním kódem.

V Pythonu se to dá ošetřit pomocí dekorátoru.

Enum?

V Javě zase anotací, pokud bys to potřeboval... což se nestává tak často :D

Tyhle dynamický změny se dělají běžně u i staticky typovaných jazyků, ne? Ne že bys na nich postavil program stejně jako na monkey patchingu, ale problém to technicky nebude. Nebo co je v tom za problém?
V c++/Jave/etc... si mužeš otevřít inspektora a prohrabat se objekty v běžícím systému + modifikovat ho? Ne, není to živá platforma.

Proč bys nemohl? Možností je víc. Ale uniká mi, proč by to někdo dělal?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 24. 03. 2016, 19:29:07
Jak se v Pythonu řeší, když vím že potřebuju nějaký int a nic jiného na daném místě nechci?

Úplně stejně, jako v ostatních jazycích, když metoda požaduje jako vstupní parametr třeba číslo měsíce (1..12) a někdo do ní chce narvat třeba 42. Má na to třeba Java datový typ? Nemá. Použiješ int a ošetříš si to vlastním kódem.

V Pythonu se to dá ošetřit pomocí dekorátoru.

Enum?

V Javě zase anotací, pokud bys to potřeboval... což se nestává tak často :D

Tyhle dynamický změny se dělají běžně u i staticky typovaných jazyků, ne? Ne že bys na nich postavil program stejně jako na monkey patchingu, ale problém to technicky nebude. Nebo co je v tom za problém?
V c++/Jave/etc... si mužeš otevřít inspektora a prohrabat se objekty v běžícím systému + modifikovat ho? Ne, není to živá platforma.

Proč bys nemohl? Možností je víc. Ale uniká mi, proč by to někdo dělal?
No, nemohl bys. Pokud nevěříš, skus si něco takovýho implementovat.

Poskytuje to insight do systemu a zrychluje to jeho pochopení. Také mužeš zkoušet dělat změny v běžícím systemu a až když najdeš cos hledal, tak to nacpat do zdrojaku. Když je system mali, vyhoda nemusí být zřejmá, když je ale velký, čas mezi změnou a viděným vysledkem je už silně nepohodlný + dostat se do spravneho stavu systemu nemusí být nejrychlejší.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 19:36:15
Právě nevím, co přesně chceš, ale pro normální použití by ti pro Javu měl stačit JRebel, který ti za chodu mění chování. Dá se to udělat i jinak, ale tohle je docela fajn řešení.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Kit 24. 03. 2016, 19:49:01
Jak se v Pythonu řeší, když vím že potřebuju nějaký int a nic jiného na daném místě nechci?

Úplně stejně, jako v ostatních jazycích, když metoda požaduje jako vstupní parametr třeba číslo měsíce (1..12) a někdo do ní chce narvat třeba 42. Má na to třeba Java datový typ? Nemá. Použiješ int a ošetříš si to vlastním kódem.

V Pythonu se to dá ošetřit pomocí dekorátoru.

Enum?

V Javě zase anotací, pokud bys to potřeboval... což se nestává tak často :D

Enum v Javě funguje trochu jinak - pro čísla měsíců to zrovna použitelné není.

Ten příklad s číslem měsíce jsem uvedl proto, že se v reálu nepoužívají jen typy int, float nebo String. Používají se i jejich podmnožiny, intervaly, řetězce určitých vlastností apod. Najednou jsou staticky typované jazyky na stejném levelu jako dynamicky typované - aplikace si to musí ošetřit samy bez významnější podpory kompilátoru.

Jistě, v Javě se k tomu dají využít anotace, v Pythonu dekorátory. Vypadá to dost podobně.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Raskal 24. 03. 2016, 19:51:59
Python je vhodny pro velke aplikace, ale ma mnohem vetsi naroky na programatora nez napriklad Java - dobry partner pro srovnani z rady staticky typovanych jazyku.

Problem Pythonu *je* zaroven jeho nejvetsi prednosti a to je prave beztypovost. Daji se v nem delat konstrukce, ktere lze v typovanem jazyce jen tezko vytvorit a to s pouzitim velmi maleho poctu radku kodu. Nemuze v nem delat kazdy, pokud ma vysledek stat za to (to plati asi vsude) a zaroven ma kazdemu co nabidnout az do jeho urovne programovani. Velke aplikace v Pythonu vyzaduji mnohem vetsi usili vynalozene na to, aby byla aplikace robustni a vyvoj udrzitelny. Neznamena to ale, ze v nem nelze delat stejne kvalitni a robustni kod jako v typovanem jazyce. Nema takovou podporu IDE jako ma Java a bylo do nej napumpovano radove mene penez nez do Javy, takze je to pochopitelne. Osobne nejvetsim zaporem Pythonu chapu to, ze nema stejne dobrou podporu pro refaktoring, jakou ma Java.

Staticky typovane jazyky nejsou konkurenty Pythonu a beztypovych jazyku a proto ani nema cenu se dohadovat o tom, ktery jazyk je lepsi. Kazdy vazne mysleny jazyk je na neco lepsi nez jiny jazyk a kazdy dobry jazyk je na neco mene vhodny nez nejaky jiny jazyk.

Python ma podporu typu parametru, ma podporu pro interface, ma podporu pro kde co.

Program v Pythonu nemusi byt pomaly a muze byt srovnatelne rychly s programem v cecku - velky krok v tom udelal projekt PyPy (http://pypy.org/ http://speed.pypy.org/). Napriklad pokud je program v cecku 5x rychlejsi nez stejny program v Pythonu, pak to je pro me vitezstvi Pythonu. PyPy je velmi zajimavy projekt nejen s ohledem na rychlost vm.

Python nema problem s tridami vytvorenymi na miru ani na jedno puziti, jako ma napriklad Java (permgem space az do verze 1.8) a metatridy jsou konceptem, ktery je mozne vyuzit, ale neni to nutne. Pokud chci stabilitu, rychlost a bezpecnost bez vetsi namahy, pak programuji v Jave. Pokud chci volnost, flexibilit a inovativni reseni, pak je Python dobra volba. V Pythonu lze za behu zmenit treba tridu a to bez neprijemnych dusledku, coz v Jave neni mozne (nejlepe je na tom asi dcevm).

Jako materialy muzu doporucit oficialni tutorial k Pythonu a studium zdrojovych kodu ruznych knihovnen pro Python, protoze je psali lidi, kteri o tom neco vedi. Nez se clovek dostane na urcitou uroven, tak to docela trva. Nejde ani tak o to znat samotny jazyk, ten neni az tak slozity. Znat jeho moznosti a vybaveni, to uz je na mnohem delsi dobu. Naucit se to pouzivat jako celek a umet v nem efektivne myslet, to uz je skoro programatoruv zivotni styl.

Pro praci a vyvoj v Pythonu urcite doporucuji nekterou z Linuxovych distribuci vybavenych balickovacim systemem.

http://python.cz/
https://www.python.org/
http://ipython.org/
https://www.jetbrains.com/pycharm/
http://www.pydev.org/
https://pypi.python.org/
https://virtualenv.pypa.io/
http://www.sqlalchemy.org/
https://wiki.python.org/moin/WebFrameworks/
http://pypy.org/
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 19:56:45
V Pythonu lze za behu zmenit treba tridu a to bez neprijemnych dusledku, coz v Jave neni mozne (nejlepe je na tom asi dcevm).

Co s tím všichni máte? K čemu by to asi tak bylo, že od 10. minuty můj program funguje jinak? To se normálně dělá trochu jinak než dynamickou změnou třídy za chodu :D
Název: Re:Python - dobré rady a praktiky
Přispěvatel: uetoyo 24. 03. 2016, 20:00:20
Problem Pythonu *je* zaroven jeho nejvetsi prednosti a to je prave beztypovost.

Já bych chtěl vysvětlení té beztypovosti (různé zdroje se v této interpretaci liší); a kdyby to rozsekl Radek Miček bylo by to fajn .)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Raskal 24. 03. 2016, 20:09:11
V Pythonu lze za behu zmenit treba tridu a to bez neprijemnych dusledku, coz v Jave neni mozne (nejlepe je na tom asi dcevm).

Co s tím všichni máte? K čemu by to asi tak bylo, že od 10. minuty můj program funguje jinak? To se normálně dělá trochu jinak než dynamickou změnou třídy za chodu :D

Je to jedna z volnosti. Ja osobne to (vyjimence) pouzivam pro patchovani funkcionality. Pokud pro me je nejaka knihovna nevyhovujici, tak misto abych ji menil, tak ji upravim (patchuju) az za behu. Urychluje to vyvoj a opravovani chyb a usnadnuje pochopeni problemu. Dulezite je, ze to zabranuje nezvysovani naroku na vyvoj a vyzname to omezuje vytvareni blokujicich problemu pro vyvoji.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: takynechápe 24. 03. 2016, 20:38:33
Takže třeba po měsíci běhu uděláš patch na běžící aplikaci a přijde ti to jako super nápad? A nebo ji jen změníš před startem aplikace jako v každém normální jazyce?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Radek Miček 24. 03. 2016, 21:19:30
V c++/Jave/etc... si mužeš otevřít inspektora a prohrabat se objekty v běžícím systému + modifikovat ho? Ne, není to živá platforma.

Na JVM to jde (tedy i v Javě to jde) - viz Java Virtual Machine Tools Interface. Inspekci umí každý debugger a modifikace umí třeba JRebel.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 24. 03. 2016, 21:24:32
Právě nevím, co přesně chceš, ale pro normální použití by ti pro Javu měl stačit JRebel, který ti za chodu mění chování. Dá se to udělat i jinak, ale tohle je docela fajn řešení.
No, já to nechci ...
JRebel není přesně to co sem myslel ... Budu se opakovat. Skus smalltalk. A nebo JS v browseru, to ti dá podobnej feel.

Jak sem řek nazačátku, dynamický typování může být úžasný, a taky úžasně strašný...a proto ho moc nemiluju.

Ačkoli, už sem si přespříliš zvykl na tu flexibilitu ... Trošku schizma
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 24. 03. 2016, 21:35:32
Já bych chtěl vysvětlení té beztypovosti (různé zdroje se v této interpretaci liší); a kdyby to rozsekl Radek Miček bylo by to fajn .)
Co na tom chceš rozsekávat? Pythonovský objekt je v principu jenom slovník (podobně jako v Javascriptu nebo Lua) s tím, že některé klíče mají speciální význam. Konkrétně třeba nás tady může zajímat atribut __dict__. A to je vše. Na tom je to celé postavené. Můžu si vytvořit prázdný objekt (bez metod) a pak si do něj přidat metody jaké budu chtít. Jaký by to potom měl být typ? Žádný, v takovém prostředí pojem typ de facto neexistuje. Smysluplně se dá mluvit jenom o tom, jestli daný objekt splňuje nebo nesplňuje nějaký protokol/rozhraní (tj. disponuje v dané chvíli nějakou množinou metod). Ale pokud bych to chtěl opravdu korektně checkovat, musím to dělat za běhu.

Samozřejmě si můžu vymyslet, že nějaké další atributy budou mít nějaký další speciální význam. Například do nějakého atributu uložím referenci na něco, čemu začnu říkat "třída" a od té doby už z toho slovníku mám s trochou bižuterie "instanci" :)

Ironií osudu je takhle postavené OOP bližší té původní myšlence (SmallTalk) než C++ nebo java :)

Úplně stejně, jako v ostatních jazycích, když metoda požaduje jako vstupní parametr třeba číslo měsíce (1..12) a někdo do ní chce narvat třeba 42. Má na to třeba Java datový typ? Nemá. Použiješ int a ošetříš si to vlastním kódem.

V Pythonu se to dá ošetřit pomocí dekorátoru.
Přesně tak. A ani nemusíme jít tak daleko, stačí nám obyčejný null ;) Jestli se někdo ptá, jak to hergot pythonisti dělají, aby jim to nepadalo na to, že někam místo stringu dají int, tak odpověď je "dělají to v principu podobně jako javisti zabezpečují, aby jim to nepadalo na NullPointerException" :)



Jinak ale mimo flame k tématu: ví někdo, jak použitelné to typování v Pythonu 3 je? Např. kolik kódu std. knihovny je pokryto typy? Jak kvalitní jsou nástroje pro statickou analýzu?

V Erlangu taky typy de facto nejsou, ale dá se použít buť velice silné "manuální typování" (místo čísla dám dvojici {number_of_seconds_since_mireks_birth, 2453461}) nebo typové anotace + docela kvalitní statická analýza (dialyzer). Plus má teda Erlang oproti Pythonu výhodu v tom, že má excelentní podporu pro práci s chybovými stavy. To Python jenom těžko může dohnat, ale tu statickou analýzu by mohl mít snad poměrně dobrou...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 24. 03. 2016, 21:38:05
Jak sem řek nazačátku, dynamický typování může být úžasný, a taky úžasně strašný...a proto ho moc nemiluju.
Moje osobní pozorování, možná chybný: mám pocit, že pythoneři nemají moc tendence dělat velký kejkle. Oproti tomu v Ruby mi přijde že to bývá zvykem daleko častěji. Proto Ruby moc nemusím.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: uetoyo 24. 03. 2016, 22:59:20
Pythonovský objekt je v principu jenom slovník (podobně jako v Javascriptu nebo Lua) s tím, že některé klíče mají speciální význam.
To asi všichni víme...

 ... našel jsem na to různé názory; proto se ptám.

I am an academic computer scientist specializing in programming languages, and yes, the word "untyped" is frequently (mis)-used in this way. It would be nice to reserve the word for use with languages that don't carry dynamic type tags, such as Forth and assembly code, but these languages are rarely used and even more rarely studied, and it's a lot easier to say "untyped" than "dynamically typed".

http://stackoverflow.com/a/9155610/2490538
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 25. 03. 2016, 00:20:41
To asi všichni víme...
No když to víš, tak si ujasni, na co se vlastně ptáš. Na definice pojmů "beztypový" a "dynamicky typovaný"? Nebo na co vlastně?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: uetoyo 25. 03. 2016, 11:02:55
Citace

No když to víš, tak si ujasni, na co se vlastně ptáš. Na definice pojmů "beztypový" a "dynamicky typovaný"?
Ptám se, jestli je správné označit jazyk jako JS nebo Python za beztypové; Protože proměnné sice nemají typ, ale hodnoty ano. Python si hlídá jestli je např. možné sečíst dvě hodnoty (jinak TypeError). Stačí si pročítat odpovědi a komentáře... jak jdou proti sobě... http://stackoverflow.com/questions/964910/is-javascript-an-untyped-language; Ale tvůj názor už znám; Dík.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 25. 03. 2016, 11:15:43
Stačí si pročítat odpovědi a komentáře... jak jdou proti sobě... http://stackoverflow.com/questions/964910/is-javascript-an-untyped-language;
No a hned v první odpovědi máš řešení: So the problem is that there's a few different definitions of untyped.

Ale tvůj názor už znám; Dík.
Nejde o názor. Prostě ta otázka nedává smysl. Někdo používá pojem "beztypový" v širším a někdo v užším smyslu. Je to asi tak jako by ses ptal, jestli je "správné" Ford Puma označovat jako "sportovní auto". Někdo to dělat bude, někdo ne.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 25. 03. 2016, 11:19:44
Citace

No když to víš, tak si ujasni, na co se vlastně ptáš. Na definice pojmů "beztypový" a "dynamicky typovaný"?
Ptám se, jestli je správné označit jazyk jako JS nebo Python za beztypové; Protože proměnné sice nemají typ, ale hodnoty ano. Python si hlídá jestli je např. možné sečíst dvě hodnoty (jinak TypeError). Stačí si pročítat odpovědi a komentáře... jak jdou proti sobě... http://stackoverflow.com/questions/964910/is-javascript-an-untyped-language; Ale tvůj názor už znám; Dík.
v JS máš pár primitivních typů a typ objekt. A ten může být beztypový a nebo typovaný (svým konstruktorem). Nic ti nebrání udělat blank objekt ({}) a pak do něj nafrkat co chceš. Nebo si můžeš udělat konstruktor a pak checkovat objekt pomocí (obj instanceof Constructor).

Jak řekl guru Mirek, ten systém prototypů je jen přidělení určitého smyslu některým fieldům (Function.prototype a obj.__proto__). Nic víc a nic míň.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 25. 03. 2016, 13:11:08
Protože proměnné sice nemají typ, ale hodnoty ano. Python si hlídá jestli je např. možné sečíst dvě hodnoty (jinak TypeError).
Může být důležité, že si to nehlídá Python, ale ta funkce pro sečtení. Takže veškeré to typování v Pythonu spočívá v tom, že hodnota má jakýsi atribut, do kterého můžeš uložit symbol IntType. A nebo Foo. Víc toho pro tebe Python neudělá.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: další 26. 03. 2016, 12:36:09
Takže Python spíše nedoporučujete na větší projekt, protože se to nedá? Slyšel jsem, že ho lidi mají rádi, ale asi nikdo z nich moc velké věci nedělá, tak nevím. Hodně adminů, které znám, tak si Python pochvalují, ale tam to chápu. Na malé věci je velmi zajímavý a asi i bližší administraci.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 26. 03. 2016, 12:58:07
Takže Python spíše nedoporučujete na větší projekt, protože se to nedá? Slyšel jsem, že ho lidi mají rádi, ale asi nikdo z nich moc velké věci nedělá, tak nevím. Hodně adminů, které znám, tak si Python pochvalují, ale tam to chápu. Na malé věci je velmi zajímavý a asi i bližší administraci.
Je CRM systém a řízení výroby větší projekt? Viz Odoo.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Viky 26. 03. 2016, 13:48:07
Takže Python spíše nedoporučujete na větší projekt, protože se to nedá? Slyšel jsem, že ho lidi mají rádi, ale asi nikdo z nich moc velké věci nedělá, tak nevím. Hodně adminů, které znám, tak si Python pochvalují, ale tam to chápu. Na malé věci je velmi zajímavý a asi i bližší administraci.

Záleží jaký projekt. To se nedá takto napsat. Je to projev diletanství a nezkušenosti pokud ti někdo jen tak napíše, že to nejde. Nedoporučuji ti moc se řídit radami tady těch místních brouků pytlíků. Většina z nich nemá žádné znalosti ani zkušenosti a jen tu na sebe dělají ramena. Akorát si někde něco přečetli a jen to tu papouškují, ani sami nevědí proč, nebo něco nepochopili, tak na to nadávají.
Např. my máme v Pythonu udělaný docela rozsáhlý (a stále rostoucí) testovací framework a pracuje se s tím velice příjemně. Původně to vznikalo ve Visual Basicu, což byl porod. Takže to už zachováváme jen kvůli starším projektům a nové děláme na Pythonu. Čili navzdory rádoby akademickým kecům místních "géniů" to jde.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 26. 03. 2016, 14:30:52
Takže Python spíše nedoporučujete na větší projekt, protože se to nedá? Slyšel jsem, že ho lidi mají rádi, ale asi nikdo z nich moc velké věci nedělá, tak nevím. Hodně adminů, které znám, tak si Python pochvalují, ale tam to chápu. Na malé věci je velmi zajímavý a asi i bližší administraci.

Záleží jaký projekt. To se nedá takto napsat. Je to projev diletanství a nezkušenosti pokud ti někdo jen tak napíše, že to nejde. Nedoporučuji ti moc se řídit radami tady těch místních brouků pytlíků. Většina z nich nemá žádné znalosti ani zkušenosti a jen tu na sebe dělají ramena. Akorát si někde něco přečetli a jen to tu papouškují, ani sami nevědí proč, nebo něco nepochopili, tak na to nadávají.
Např. my máme v Pythonu udělaný docela rozsáhlý (a stále rostoucí) testovací framework a pracuje se s tím velice příjemně. Původně to vznikalo ve Visual Basicu, což byl porod. Takže to už zachováváme jen kvůli starším projektům a nové děláme na Pythonu. Čili navzdory rádoby akademickým kecům místních "géniů" to jde.
OMG, nikdo tady netvrdí že to nejde (odmyslíme těch pár trotlů školou povinných nazačátku diskuze). Pouze padlo že dynamické typování je vynikající nástroj na střelení se do nohy, když nevíš co děláš. Když víš co děláš a máš unit testy, je to super tool. Systémy v jazykách ála-python jsou snadno rozšiřitelný, pokud ti ale návrh stojí za hovno, posereš se a budeš litovat že nemáš statický typování.

Když ti někdo řekne, python není dobrej na velký projekty, můžeš to vyložit třema způsoby.
Ten člověk je debil.
Ten člověk ví, že výkon je někdy u velkej projektů i důležitej ...
Ten člověk ví že musíš bejt dobrej (programátor|architekt -> kdokoli kdo navrhne tu monstrozitu), jinak ti to ustřelí nohu, a čím větší to bude, tím ti jí to ustřelí víc. Taky ten člověk ví že klienti sou debilové, stejně jako šéf kterej chce vše hned, nejlíp včera, takže návrh bude obvykle nahovno ...

To, že v práci máte [...] udělaný v pythonu nikoho nezajímá a o ničem to nevypovídá ...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 26. 03. 2016, 14:35:30
Např. my máme v Pythonu udělaný docela rozsáhlý (a stále rostoucí) testovací framework a pracuje se s tím velice příjemně. Původně to vznikalo ve Visual Basicu, což byl porod. Takže to už zachováváme jen kvůli starším projektům a nové děláme na Pythonu. Čili navzdory rádoby akademickým kecům místních "géniů" to jde.
Nikdo myslím netvrdil, že to nejde. Znám projekt, který je postavený na Pythonu a má desetitisíce řádků. Otázka je, jestli je to racionální volba. Python má prostě svoje specifika, který člověk musí znát a zvážit, než se do toho pustí.

Jenom tak namátkou, co mi slina na jazyk přinese (při skutečném zvažování je potřeba to vzít z gruntu):

Ze začátku mě naláka rychlost vývoje, snadnost úprav, dostupnost vývojářů a "živost" projektu.

GIL! - pokud uvažuju nad serverovou aplikací, je GIL koule na noze. Vyřeší se to tím, že se spustí X oddělených VM. Musím řešit jejich komunikaci na vyšší vrstvě. PyPy není AFAIK dostatečně zralé, aby se na něj dalo spolehnout. Můžu zkusit async.io apod., ale dostávám se do oblasti poněkud dobastlené, bez first-class podpory v jazyce (docela připomíná promises v JS).

Dynamičnost/beztypovost - musím si setsakramentsky dávat pozor na štábní kulturu. Když třeba někam ukládám nějaká data, musím zevrubně zabezpečit, aby mi tam semtam nespadla hodnota, která tam být nemá (z vlastní zkušenosti: není nic otravnější než když člověk má proces, který běží hodiny, načítá nějaká data a po pár hodinách spadne, protože se někde objevil None místo []. Ok, nemělo to tam být, tak to ve zdrojáku ošetříme, spustíme znovu a ono to po pár hodinách spadne na None někde jinde).

Ať jsou unittesty jaké chtějí zevrubné, chyby v produkci budou. Musím nasazovat nějaký logovací systém, který mi podá dostatečně dobré informace, k jaké chybě a kde došlo (Sentry apod.)

Nakonec mě to donutí skončit u nějakých úplně oddělených komponent (buzzword: microservices), cena komunikace a náročnost na schopnosti analytika/designéra roste.

Na větším pojektu se snadnost úprav přehoupne do nesnadnosti úprav. Co bylo na začátku výhodou, se stane nevýhodou.

atd. atd. atd. tohle je fakt jenom tak v rychlosti, co mě momentálně napadlo. Jenom pro ilustraci, že rozhodnout se pro nebo proti pythonu není snadná volba a hraje tam roli spousta věcí. U jazyků, které jsou designované s myšlenkou na větší serverové aplikace od začátku, je zvažování úplně jiné. U pythonu bych to shrnul asi na "Určitě to jde. Ale zvládneme to my? A stojí nám to za to?"
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 26. 03. 2016, 14:42:12
Koukám, že čumil napsal paralelně se mnou prakticky to samý :)

...což mi připomnělo Jistě pane ministře:

- Celá státní správa je tu proto, aby vám radila!
- Všichni radíte stejně!
- To svědčí o správnosti udílených rad.

:)))
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 26. 03. 2016, 14:59:05
Úplně stejně, jako v ostatních jazycích, když metoda požaduje jako vstupní parametr třeba číslo měsíce (1..12) a někdo do ní chce narvat třeba 42. Má na to třeba Java datový typ? Nemá. Použiješ int a ošetříš si to vlastním kódem.

V Pythonu se to dá ošetřit pomocí dekorátoru.
Přesně tak. A ani nemusíme jít tak daleko, stačí nám obyčejný null ;) Jestli se někdo ptá, jak to hergot pythonisti dělají, aby jim to nepadalo na to, že někam místo stringu dají int, tak odpověď je "dělají to v principu podobně jako javisti zabezpečují, aby jim to nepadalo na NullPointerException" :)
Taky to považují za největší omyl (https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/)? :)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 26. 03. 2016, 15:19:56
největší omyl? :)
Tyjo, super článek, dík! ...a jako obvykle, největší zmatek a prasárna je v C++, ten bod 6 je fakt výživnej :))
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 26. 03. 2016, 16:02:01
největší omyl? :)
Tyjo, super článek, dík! ...a jako obvykle, největší zmatek a prasárna je v C++, ten bod 6 je fakt výživnej :))
Co je největší prasárna je asi docela subjektivní. V c++ je aspoň k dispozici boost::optional a snad se ujme i not_null z gsl. Maybe z Haskellu to není, ale na to, co si c++ historicky táhne, je to překvapivě snesitelné.
Název: Re:python - dobre rady & praktiky
Přispěvatel: pyN00b 26. 03. 2016, 16:53:48
Důležité je pochopit toto http://blog.startifact.com/posts/older/what-is-pythonic.html a další odkazy https://www.google.cz/search?client=ubuntu&channel=fs&q=pythonic&ie=utf-8&oe=utf-8&gfe_rd=cr&ei=poHzVtCxHMiI8QfcpYaQCg

clanek jsem moc nepobral / moc jsem si z nej neodnesl. ale doporucujes treba: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html ?

diky :)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: gl 26. 03. 2016, 19:27:50
Dynamičnost/beztypovost - musím si setsakramentsky dávat pozor na štábní kulturu. Když třeba někam ukládám nějaká data, musím zevrubně zabezpečit, aby mi tam semtam nespadla hodnota, která tam být nemá (z vlastní zkušenosti: není nic otravnější než když člověk má proces, který běží hodiny, načítá nějaká data a po pár hodinách spadne, protože se někde objevil None místo []. Ok, nemělo to tam být, tak to ve zdrojáku ošetříme, spustíme znovu a ono to po pár hodinách spadne na None někde jinde).

Ať jsou unittesty jaké chtějí zevrubné, chyby v produkci budou. Musím nasazovat nějaký logovací systém, který mi podá dostatečně dobré informace, k jaké chybě a kde došlo (Sentry apod.)

Je elixir, který zde často propagujete, v tomto jiný?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 27. 03. 2016, 01:56:41
Úplně stejně, jako v ostatních jazycích, když metoda požaduje jako vstupní parametr třeba číslo měsíce (1..12) a někdo do ní chce narvat třeba 42. Má na to třeba Java datový typ? Nemá. Použiješ int a ošetříš si to vlastním kódem.

V Pythonu se to dá ošetřit pomocí dekorátoru.
Přesně tak. A ani nemusíme jít tak daleko, stačí nám obyčejný null ;) Jestli se někdo ptá, jak to hergot pythonisti dělají, aby jim to nepadalo na to, že někam místo stringu dají int, tak odpověď je "dělají to v principu podobně jako javisti zabezpečují, aby jim to nepadalo na NullPointerException" :)
Taky to považují za největší omyl (https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/)? :)
?? Proč má Objective C 4 typy null ??
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 27. 03. 2016, 04:23:10
Je elixir, který zde často propagujete, v tomto jiný?
Ano. Všechno, co jsem psal o Erlangu, platí (až na drobnosti) i o Elixiru:
V Erlangu taky typy de facto nejsou, ale dá se použít buť velice silné "manuální typování" (místo čísla dám dvojici {number_of_seconds_since_mireks_birth, 2453461}) nebo typové anotace + docela kvalitní statická analýza (dialyzer). Plus má teda Erlang oproti Pythonu výhodu v tom, že má excelentní podporu pro práci s chybovými stavy. To Python jenom těžko může dohnat, ale tu statickou analýzu by mohl mít snad poměrně dobrou...
Největší rozdíl je v tom, že Erlang/Elixir počítá s tím, že dochází k chybám, a umí se s nimi skvěle vypořádat. Mottem se stalo heslo "Let it crash!" :) Viz např. http://c2.com/cgi/wiki?LetItCrash
Název: Re:Python - dobré rady a praktiky
Přispěvatel: p 27. 03. 2016, 04:23:16
Jaky je vas nazor na to, ze aplikace udelana ve flasku bezi i po skonceni dotazu? Neni to trochu uchylny, kdyz HTTP je bezstavovy protokol?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 27. 03. 2016, 09:10:12
Jestli se chceš něco dozvědět, doporučuji psát na příslušná místa, ke se vyskytují lidé co v Pythonu programují, ne tady na rootu kde je akorát banda trolů...
Koukni třeba na http://python.cz (http://python.cz) např Pyonýři sou fajn facebook skupina, kde sou lidi co programují a mnohdy velké projekty...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: pyN00b 27. 03. 2016, 09:39:44
Jestli se chceš něco dozvědět, doporučuji psát na příslušná místa, ke se vyskytují lidé co v Pythonu programují, ne tady na rootu kde je akorát banda trolů...
Koukni třeba na http://python.cz (http://python.cz) např Pyonýři sou fajn facebook skupina, kde sou lidi co programují a mnohdy velké projekty...

diky, to zkusim. ale padlo tu par docela zajimavych myslenek na ktery bych rad odpovedel.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: zboj 27. 03. 2016, 09:41:22
Úplně stejně, jako v ostatních jazycích, když metoda požaduje jako vstupní parametr třeba číslo měsíce (1..12) a někdo do ní chce narvat třeba 42. Má na to třeba Java datový typ? Nemá. Použiješ int a ošetříš si to vlastním kódem.

V Pythonu se to dá ošetřit pomocí dekorátoru.
Přesně tak. A ani nemusíme jít tak daleko, stačí nám obyčejný null ;) Jestli se někdo ptá, jak to hergot pythonisti dělají, aby jim to nepadalo na to, že někam místo stringu dají int, tak odpověď je "dělají to v principu podobně jako javisti zabezpečují, aby jim to nepadalo na NullPointerException" :)
Taky to považují za největší omyl (https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/)? :)
?? Proč má Objective C 4 typy null ??
Pro instance, třídy, z C a jako objekt do kolekcí.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: perceptron 27. 03. 2016, 10:37:08
Jaky je vas nazor na to, ze aplikace udelana ve flasku bezi i po skonceni dotazu? Neni to trochu uchylny, kdyz HTTP je bezstavovy protokol?
neni. takto funguju http aplikace v .net aj jave. aplikace bezi furt, obsluhuje requesty. session handling je trivialny
Název: Re:Python - dobré rady a praktiky
Přispěvatel: it expert 27. 03. 2016, 10:38:20
Jaky je vas nazor na to, ze aplikace udelana ve flasku bezi i po skonceni dotazu? Neni to trochu uchylny, kdyz HTTP je bezstavovy protokol?

Úplně v pohodě. Apache také běží po skončení a čeká na další request. V tom Flasku je to stejné. Čeká na další request. V paměti si drží spojení do databáze, které kdyby se měly znovu navazovat při každém requestu? tak by docházelo k neuměrnému zpomalování.

Dále je dobré si mezi requesty držet další objekty, různé countery, nacachované šablony, otevřené soubory, spojení do jiných komponent (memcache, redis, message brokery apod.).
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 27. 03. 2016, 11:10:22
Jestli se chceš něco dozvědět, doporučuji psát na příslušná místa, ke se vyskytují lidé co v Pythonu programují, ne tady na rootu kde je akorát banda trolů...
Koukni třeba na http://python.cz (http://python.cz) např Pyonýři sou fajn facebook skupina, kde sou lidi co programují a mnohdy velké projekty...
Hej, a taky info rozhodně nebude ovlivněný python evangelisty... Blbče, aspoň měj dostatek slušnusti přečíst si co padlo před tvím komentem než začneš nalepkovat trolli.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 27. 03. 2016, 11:29:20
Jestli se chceš něco dozvědět, doporučuji psát na příslušná místa, ke se vyskytují lidé co v Pythonu programují, ne tady na rootu kde je akorát banda trolů...
Koukni třeba na http://python.cz (http://python.cz) např Pyonýři sou fajn facebook skupina, kde sou lidi co programují a mnohdy velké projekty...
Hej, a taky info rozhodně nebude ovlivněný python evangelisty... Blbče, aspoň měj dostatek slušnusti přečíst si co padlo před tvím komentem než začneš nalepkovat trolli.
A ty si přečti aspoň nadpis vlákna a pak možná pochopíš proč ho odkazuji mimo root.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 27. 03. 2016, 12:13:29
Zkus si přečíst sekci Hnutí za dobrý kód z http://www.abclinuxu.cz/blog/bystroushaak/2014/7/python-poznamky

Jinak osobně jsem v pythonu dělal na projektu, který měl přes 40k řádek podle CLOC (tzn bez prázdných řádků, komentářů, docstringů a tak). Nebyl s tím vůbec žádný problém, dělali jsme to ve dvou a šlo to v pohodě. Možná za to mohla microservices architektura, ale prostě žádné hroucení na hlavu se nekonalo. Ani co se týče kódu, ani co se týče výkonu, naopak se to krásně škáluje. Umím si představit, že by to stejným způsobem šlo klidně o řád dál bez nějakého stresu.

Například v Seznamu mají systémy psané v pythonu o rozsahu stovek tisíc až milionů řádek a podle všeho s tím nemají problém, naopak pořád nabírají nové lidi. To samé Google. To samé Redhat.

Imho problém těhle threadů o pythonu je, že sem lezou javisti, kteří kolikrát neumí pořádně ani tu javu a pak javí v pythonu a diví se, že jim to nejde. Python je prostě úplně odlišná filosofie, jak co se týče návrhu jazyka, tak co se týče architektury a praktik považovaných za dobré a špatné. Nikde jinde jsem to neviděl takhle ostře vyděleno.

„Chyba“ pythonu je, že základy jsou tak lehké, že se je za týden naučí každý. Když pak ovládne syntaxi, ale vůbec nepochopí nic o zbytku filosofie, tak to končí špatně. Pár těhle projektů jsem viděl a to bych blil.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Radek Miček 27. 03. 2016, 12:47:06
Zkus si přečíst sekci Hnutí za dobrý kód z http://www.abclinuxu.cz/blog/bystroushaak/2014/7/python-poznamky

Jinak osobně jsem v pythonu dělal na projektu, který měl přes 40k řádek podle CLOC (tzn bez prázdných řádků, komentářů, docstringů a tak). Nebyl s tím vůbec žádný problém, dělali jsme to ve dvou a šlo to v pohodě. Možná za to mohla microservices architektura, ale prostě žádné hroucení na hlavu se nekonalo. Ani co se týče kódu, ani co se týče výkonu, naopak se to krásně škáluje. Umím si představit, že by to stejným způsobem šlo klidně o řád dál bez nějakého stresu.

IDE nebo jiné nástroje pro Python vám při refaktoringu typicky pomohou mnohem méně než kompilátory moderních staticky typovaných jazyků (a nezmění to ani pokročilejší IDE jako PyCharm). IMO udržovat kód v Pythonu je tedy o dost náročnější (na druhé straně to zřejmě kompenzuje dostatek programátorů).
Název: Re:Python - dobré rady a praktiky
Přispěvatel: php 27. 03. 2016, 12:59:48
IMO udržovat kód v Pythonu je tedy o dost náročnější (na druhé straně to zřejmě kompenzuje dostatek programátorů).

Dostatek nevím, ale jsou levní a to je výhoda. Je to takové lepší PHP a u nás cena rozhoduje. Někde si manažer přečte, že se v tom vývíjí rychleji, což se mi také moc nezdá. Kvalitní Java programátor je tak za dvojnásobek skriptovacích mágů.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 27. 03. 2016, 19:53:37
IDE nebo jiné nástroje pro Python vám při refaktoringu typicky pomohou mnohem méně než kompilátory moderních staticky typovaných jazyků (a nezmění to ani pokročilejší IDE jako PyCharm). IMO udržovat kód v Pythonu je tedy o dost náročnější (na druhé straně to zřejmě kompenzuje dostatek programátorů).

Mě s refactoringem nejvíc pomáhají unittesty. Dělal jsem nějakou dobu i v Javě a D a nemám pocit, že by to v pythonu bylo nějak signifikantně slabší. Asi nejhorší refactoring v životě jsem zažil v C, které by podle téhle logiky mělo být refactorovací bonanza (zkoušel jsem jak eclipse, tak netbeans). Ono to asi nebude ta nejideálnější metrika použitelnosti jazyka.

Jinak já moc nepobírám tyhle spekulace, navíc ještě v tomhle threadu, kde chtěl radu ohledně praktik v pythonu. Máte zkušenost s pythonem? Podělte se. Nemáte? Váš názor je irelevantní.

Tyhle diskuze, kde deset javistů v pythonu strašně postrádá Y, což jim dokazuje, že je k ničemu a jednoznačně „horší“ doslova postrádají smysl. To není nic jiného, než jen poměřování penisů, navíc stylem „ten tvůj jsem sice neviděl, ale jsem si jistý, že táta má větší“.

Programování v pythonu je docela jednoduše získatelný žážitek. Pokud vás fakt tak hrozně zajímá, jak se v něm dělá, nemá smysl si řádku za řádkou vyměňovat zkušenosti, nebo čekat, až technologie umožní přenos myšlenek, ale prostě si to zkuste. Mám z toho pocit, že by to zabralo míň času, než tyhle věčné spekulace. Možná sedne, možná ne.


Když už jsme v tom, přidám osobní zkušenost:

Já jsem měl kdysi (~2011) periodu, kdy jsem asi dva roky na python nesáhl a dělal jsem jen v D. Pak jsem měl potřebu v něm něco napsat a měl jsem hrozný problém - vždyť to nemá statické typování. Tohle se přece může rozbít, tohle tady není protected, ani private, co když mi tu metodu někdo použije? Chvíli jsem měl pocit, že je to fakt sračka. Vážně. Asi měsíc jsem měl s tímhle psychický problém.

Pak jsem v něm napsal ten script a ten byl (dostatečně) rychlý a efektivní a měl jsem ho hotový za chvíli. To mě překvapilo. Myšlenky se v pythonu dají tak nějak zapisovat příměji, bez použití tolik sraček kolem, o které mi ve skutečnosti vůbec nejde a vlastně mě nezajímají a ani je nepotřebuju. Došlo mi, že jsem omezoval sám sebe, řešil blbosti a vytvářel si virtuální problémy, které ve skutečnosti neexistovaly.

Tak jsem začal psát víc a víc, až jsem začal dělat jen v pythonu, protože jsem v několikrát produktivnější, než v D. Produktivita je vážně ta jediná reálná metrika, která mě zajímá a většinou zajímá i ostatní, jinak by jsme všichni psali v assembleru.

Jsem v tom produktivnější? To zcela jasně znamená, že je to pro mě lepší. Jedno jestli Python, Lisp, nebo Smalltalk. Život je moc krátký, abych ho mohl trávit výrobou abstraktních továren továren, které stejně používám jen proto, abych mohl nějak ojebat typový systém.

Jazyk, kde chrlím funkcionalitu pětkrát rychleji je pro mě lepší, i kdybych v něm náhodou měl dvojnásobek bugů. Jasně, asi to není nic pro kardiostimulátory, řidící systémy elektráren, nebo různé jiné kritické aplikace, ale tam nepatří ani zbytek toho, co se běžně používá. Tam by měly být formálně verifikované jazyky.

Rád bych zdůraznil, že python nevede na dvojnásobek bugů, i když většina javistů má tenhle pocit. Občas tam nějaké bugy v typech jsou, ale většinou je to výsledkem špatného návrhu, než nějaká bolest typového systému (oblíbené je například znásilňovat dicty na nepopsaný transportní formát, což jde udělat jinde taky, třeba přes JSON a skoro vždycky je to blbě). Typový systém navíc v divočejším použití OOP poměrně rychle ztrácí výhody, protože ani kompilátor nemůže vědět, co kde kam přijde v době runtime.


Ještě k té produktivitě:

Kdysi jsem si takhle koupil mechanickou klávesnici za tři tisíce. Měl jsem z toho radost, vypadala cool a všechno. Fakt super. Užíval jsem si psaní na Cherry MX blue a říkal si, jak krásně rychle na tom píšu.

Pak jsem si sehnal použitou Apple klávesnici za pár stovek, jen abych si vyzkoušel, jestli je použitelná ta na macbooku, který jsem si tenkrát chtěl koupit (má stejný layout). Velmi mě udivilo, že se mi na té klávesnici píše o poznání rychleji a skoro vůbec to neunavuje ruce. Pak mě konečně napadlo si to změřit a zjistil jsem, že jen změnou klávesnice, bez jakékoliv další snahy jsem získal navíc 20 slov za minutu.

Tu mechaniku jsem měl docela rád. Do jisté míry jsem si na ní zakládal, měl jsem z ní pocit dobré investice a tak. Ale prostě se těžko můžu hádat s produktivitou.

Mechaniky jsem se zbavil, i když měla být lepší, vypadala víc cool, dělala klikavé zvuky a prostě vůbec, byla to klávesnicovatější klávesnice. Různí lidé, kteří u mě mechaniku viděli to nemohli moc pochopit. Co mě vedlo k přechodu na membránovku s plochými tlačítky? Vždyť to přece musí být horší.

Stejný pocit mi přijde, že mají lidé z Javy a C# z Pythonu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 27. 03. 2016, 20:08:36
Python je ta mechanika? Jako že vypadá cool, ale jinak to není ono. To souhlasím, tak nějak mi to vždy připadlo.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: x 27. 03. 2016, 21:29:13
(oblíbené je například znásilňovat dicty na nepopsaný transportní formát, což jde udělat jinde taky, třeba přes JSON a skoro vždycky je to blbě).

Muzes to prosim trochu rozvest? Dekuji
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Radek Miček 27. 03. 2016, 22:01:18
IDE nebo jiné nástroje pro Python vám při refaktoringu typicky pomohou mnohem méně než kompilátory moderních staticky typovaných jazyků (a nezmění to ani pokročilejší IDE jako PyCharm). IMO udržovat kód v Pythonu je tedy o dost náročnější (na druhé straně to zřejmě kompenzuje dostatek programátorů).

Asi nejhorší refactoring v životě jsem zažil v C, které by podle téhle logiky mělo být refactorovací bonanza (zkoušel jsem jak eclipse, tak netbeans). Ono to asi nebude ta nejideálnější metrika použitelnosti jazyka.

Proto jsem psal moderní staticky typovaný jazyk. Tím nemyslím Javu nebo C, ale myslím tím například OCaml, F#, Haskell a do jisté míry i Scalu.

Citace
Jinak já moc nepobírám tyhle spekulace, navíc ještě v tomhle threadu, kde chtěl radu ohledně praktik v pythonu. Máte zkušenost s pythonem? Podělte se. Nemáte? Váš názor je irelevantní.

To není spekulace, ale moje zkušenost s Pythonem a PyCharm.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 03:34:05
Programování v pythonu je docela jednoduše získatelný žážitek. Pokud vás fakt tak hrozně zajímá, jak se v něm dělá, nemá smysl si řádku za řádkou vyměňovat zkušenosti, nebo čekat, až technologie umožní přenos myšlenek, ale prostě si to zkuste. Mám z toho pocit, že by to zabralo míň času, než tyhle věčné spekulace. Možná sedne, možná ne.
Python ze začátku (možná po chvilce) sedne každému, protože je to prostě fajn jazyk na rychlé věci. Debata je o tom, za jakých podmínek je to i vhodný jazyk na velké a serverové věci. A myslím, že tady zaznělo několik názor ze zkušenosti, která se těžko získává. Jistě, zkusit si můžeš všechno, ale nepřál bych nikomu strávit rok vývojem něčeho, aby pak zjistil, že šel slepou uličkou. Ne že by to tak nutně muselo skončit, ale nějaká netriviální pravděpodobnost tam je. Koneckonců asi nikdo (možná kromě Franty Fuky) nebude doporučovat psát velké a serverové věci v Lua...

Život je moc krátký, abych ho mohl trávit výrobou abstraktních továren továren, které stejně používám jen proto, abych mohl nějak ojebat typový systém.
Pokud potřebuješ (víc než jednou za uherský rok) ojebávat typový systém, tak něco děláš špatně. Typový systém je od toho, aby zamezil věcem, které bys z dobrého důvodu dělat neměl.

Občas tam nějaké bugy v typech jsou, ale většinou je to výsledkem špatného návrhu
Nebo prostě překlepu, který neodhalily unittesty. To je právě ta největší bolest.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 28. 03. 2016, 05:42:09
Python je ta mechanika? Jako že vypadá cool, ale jinak to není ono. To souhlasím, tak nějak mi to vždy připadlo.

Ta mechanika je ta mechanika. Pointa je, že pokud budu v něčem efektivnější, nemá smysl se držet něčeho, kde (tolik) efektivní nejsem. Pokud si někdy zkusím (třeba) OCaml a zjistím, že v něm jsem efektivnější, na python si ani nevzpomenu a pojedu v OCamlu.

Chce to ale zkoušet, ne sedět a kritizovat optikou jazyka, ve kterém právě dělám. Neustálé zkoušení mi přijde jako součást práce programátora. Imho to zajišťuje, že nezatuhneš a nezůstaneš sedět ve své divné díře, ze které se ti zdá všechno ostatní horší nikoliv proto, že by to tak bylo, ale protože s tím nemáš (dostatečnou) osobní zkušenost.

Přijde mi, že speciálně Javisti tímhle přístupem vynikají. Možná za to může celá kultura kolem, včetně vysokých škol, kde se jednou naučí pár patternů, pak v tom 10 let dělají a získají pocit, že takhle je to správně a všechno ostatní je špatně, moderní mumbo-jumbo, ve kterém dělají hipsteři a které je jinak úplně nahovno, protože není Java. Já bych se skoro vsadil, že dřív někde na usenetu úplně stejně reagovali programátoři ve Fortranu, když jim začala Java ukrajovat koláč.

Muzes to prosim trochu rozvest? Dekuji

V pythonu občas lidi (hlavně začátečníci) vrací z funkcí dicty a píšou funkce, které berou dicty, protože je to jednoduché a rychlé. Pokud k tomu nedodají extenzivní dokumentaci, bývá to časem totálně neudržitelné. Tohle není problém Pythonu, ale špatného návrhu.

Všude kde člověk pracuje s daty, které nemají (vynucované) schéma, jako třeba XML / XSD / DTD, tak bude narážet na problémy stejného druhu. Pokud si uděláš třeba JSON API, nebo connector na microservices v Javě, budeš to muset taky řešit a reagovat na všechno možné, co ti tam kdo posílá chybovými hláškami.

Řešením imho není tohle prohlásit za nemožné a zapovězené, ale naučit se, že vyvolání výjimky, když program data neumí zpracovat je prostě součást protokolu komunikace.

To není spekulace, ale moje zkušenost s Pythonem a PyCharm.

Nemyslel jsem tebe (proto ta věta začíná slovem „Jinak“, jakože to už nepatří k tomu na co jsem reagoval po citaci), myslel jsem obecně tohle vlákno, které je komentářů v tomhle duchu plné.

Pokud potřebuješ (víc než jednou za uherský rok) ojebávat typový systém, tak něco děláš špatně. Typový systém je od toho, aby zamezil věcem, které bys z dobrého důvodu dělat neměl.

<trollface>Vida. Já myslel, že na ojebávání typového systému vznikla celá disciplína, která si s velkou slávou říká „design patterns“.</trollface>

Nebo prostě překlepu, který neodhalily unittesty. To je právě ta největší bolest.

Vážně? Pro mě je největší bolest Unicode, překlepy se mi od doby co v editoru používám linter (pep8, pyflakes a pylint) prakticky nestávají.

Nedávno jsem zase strávil několik hodin řešením problému aplikace, která se musí porvat s libovolnou webstránkou. To je pak zadek ladit kódování, když python na půlce věcí vyhazuje UnicodeDecodeError a druhou půlku zmutuje do nečitelného textu. Do toho stránky, co deklarují kódování blbě, stránky co ho nedeklarují vůbec a stránky, které mají kódování dobře, ale na serveru se do nich vkládá místy obsah, který ho má blbě.

Kdybych dostal pětikorunu pokaždé, když prokleju práci s kódováním textů, tak bych asi mohl odejít do důchodu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Viky 28. 03. 2016, 10:35:35
Debata je o tom, za jakých podmínek je to i vhodný jazyk na velké a serverové věci.

O žádných serverových věcech tazatel nenapsal ani písmeno. To si tam dofantazírovali ostatní zdejší kecálisté a na základě těchto a podobně vykonstruovaných fantasmagorií dospěli k závěru, že Python není vhodný jazyk na větší projekty.

Jak už jsem zmínil, my máme v Pythonu framework čítající desítky tisíc řádků kódu, dělá totéž co dřívější o řád větší visualbasicovský, akorát je to narozdíl od toho přehlednější a mnohem lépe a snadněji se to dá rozvíjet a udržovat. Jde o framework určený k validačním a unit testům softwaru, který vyvíjíme, tedy o nástroj čistě k interním účelům, s nímž pracují jen vývojáři a sami pro sebe si jej také podle potřeby dotvářejí.

Jde o větší projekt? Ano. Je pro něj Python vhodný? Ano. Je tedy pravdivé tvrzení, že se Python k takovým věcem nehodí? Ne.
Q.E.D.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 28. 03. 2016, 11:07:27
Zkus si přečíst sekci Hnutí za dobrý kód z http://www.abclinuxu.cz/blog/bystroushaak/2014/7/python-poznamky

Jinak osobně jsem v pythonu dělal na projektu, který měl přes 40k řádek podle CLOC (tzn bez prázdných řádků, komentářů, docstringů a tak). Nebyl s tím vůbec žádný problém, dělali jsme to ve dvou a šlo to v pohodě. Možná za to mohla microservices architektura, ale prostě žádné hroucení na hlavu se nekonalo. Ani co se týče kódu, ani co se týče výkonu, naopak se to krásně škáluje. Umím si představit, že by to stejným způsobem šlo klidně o řád dál bez nějakého stresu.

IDE nebo jiné nástroje pro Python vám při refaktoringu typicky pomohou mnohem méně než kompilátory moderních staticky typovaných jazyků (a nezmění to ani pokročilejší IDE jako PyCharm). IMO udržovat kód v Pythonu je tedy o dost náročnější (na druhé straně to zřejmě kompenzuje dostatek programátorů).
Toto je chybný přístup, IDE jako PyCharm to nedělá, protože neexistuje praktická potřeba to dělat, jinak IDE jako PyCharm obsahuje gramatiku jazyka a ve spojení například s debuggerem má všechny předpoklady k tomu, aby si typy zjistilo samo a uložilo například do slovníku, nebo formou anotací do zdrojového textu. Není proto těžké udělat plugin, který by to obstaral včetně vazby na refaktoring.

Vyhozená výjimka je totéž co chyba během překladu. Kompilace není časově méně náročná něž samotný běh programu (jak tomu bývalo dříve), psychologicky není rozdíl v tom, zda chybu vám odhalí kompilátor, nebo výjimka za běhu během ladění. V obou případech na to čekáte stejně dlouho. Je-li aplikace psána rozumně, s vhodnou granularitou.

Výhody silně typových jazyků se projeví nejvíce u špageti kódu, což byla motivace k jejich vytvoření.

Nepochopení vzniká aplikací statického přístupu na dynamický jazyk. Dynamický jazyk je světe div se dynamický, a ta dynamičnost byla jednou z motivací, co stála u jeho zrodu a je to jeho výhoda, která odpovídá zvolenému přístupu. Opačně to platí o statických jazycích.

K čemu je vám řešit spor dynamický versus statický jazyk, velký a malý projekt, když de facto logika aplikace (80% kódu v netestovatelné podobě) bývá často uložena v xml definicích, které dynamicky interpretuje jádro aplikace (20%). Dynamické jazyky berličku xml často ani nepotřebují, deklaraci chovaní aplikace, můžete elegantně zapsat standardními prostředky jazyka, nemusíte mít pak vlastní kompilátor (= jádro aplikace), které ty deklarace přeloží do výkonného kódu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: norm 28. 03. 2016, 11:20:26
Chce to ale zkoušet, ne sedět a kritizovat optikou jazyka, ve kterém právě dělám. Neustálé zkoušení mi přijde jako součást práce programátora. Imho to zajišťuje, že nezatuhneš a nezůstaneš sedět ve své divné díře, ze které se ti zdá všechno ostatní horší nikoliv proto, že by to tak bylo, ale protože s tím nemáš (dostatečnou) osobní zkušenost.

Jenže kolik se toho dá stihnout? Pochopím to u lidí, kteří mají programování jak koníčka a v ničem pořádně neumí. Tam se to mění bez problémů. Pokud by sis vzal jen Javu a Python, tak to máš tak na pět let práce a to zapomeň na nějaké párty, rodiny a podobné věci. Normální lidi nemají šanci vůbec se naučit ani JEDEN jazyk pořádně. Běžný Java vývojář také o jazyku nic moc neví, což se často bere jako výtka. U ostatních jazyků je to podobné.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Radek Miček 28. 03. 2016, 11:24:31
Zkus si přečíst sekci Hnutí za dobrý kód z http://www.abclinuxu.cz/blog/bystroushaak/2014/7/python-poznamky

Jinak osobně jsem v pythonu dělal na projektu, který měl přes 40k řádek podle CLOC (tzn bez prázdných řádků, komentářů, docstringů a tak). Nebyl s tím vůbec žádný problém, dělali jsme to ve dvou a šlo to v pohodě. Možná za to mohla microservices architektura, ale prostě žádné hroucení na hlavu se nekonalo. Ani co se týče kódu, ani co se týče výkonu, naopak se to krásně škáluje. Umím si představit, že by to stejným způsobem šlo klidně o řád dál bez nějakého stresu.

IDE nebo jiné nástroje pro Python vám při refaktoringu typicky pomohou mnohem méně než kompilátory moderních staticky typovaných jazyků (a nezmění to ani pokročilejší IDE jako PyCharm). IMO udržovat kód v Pythonu je tedy o dost náročnější (na druhé straně to zřejmě kompenzuje dostatek programátorů).

IDE jako PyCharm obsahuje gramatiku jazyka a ve spojení například s debuggerem má všechny předpoklady k tomu, aby si typy zjistilo samo a uložilo například do slovníku, nebo formou anotací do zdrojového textu. Není proto těžké udělat plugin, který by to obstaral včetně vazby na refaktoring.

Udělat takový plugin je prakticky nemožné, neboť typová rekonstrukce i pro jednoduché typové systémy (jako je například System F) je nerozhodnutelná. A pro (rozumné) otypování netriviálních programů v Pythonu potřebujete mnohem složitější typový systém (hádám minimálně na úrovni DOT).
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Radek Miček 28. 03. 2016, 12:00:01
BTW kromě statického typového systému mi v Pythonu chybí podpora pro vytváření neměnných tříd a neměnné kolekce.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 12:02:01
V pythonu občas lidi (hlavně začátečníci) vrací z funkcí dicty a píšou funkce, které berou dicty, protože je to jednoduché a rychlé. Pokud k tomu nedodají extenzivní dokumentaci, bývá to časem totálně neudržitelné. Tohle není problém Pythonu, ale špatného návrhu.
Ono to je ale úplně jedno, jestli vrací slovník, pole nebo n-tici. Problém je v tom, že do jakékoliv složitější datové struktury se časem může zatoulat typ, který tam být neměl. Pokud má být špatným návrhem používat jakékoliv složitější/složené datové struktury, tak je něco špatně...

Všude kde člověk pracuje s daty, které nemají (vynucované) schéma, jako třeba XML / XSD / DTD
Schema ale můžeš mít jenom mimo python. Jakmile ta data nahraješ do pythonu, můžeš stčit cokoli kamkoli a žádné schema k dispozici nemáš. Pokud si nenapíšeš objekt, který bude validovat typ při každé operaci s tou strukturou.

, tak bude narážet na problémy stejného druhu. Pokud si uděláš třeba JSON API, nebo connector na microservices v Javě, budeš to muset taky řešit a reagovat na všechno možné, co ti tam kdo posílá chybovými hláškami. Řešením imho není tohle prohlásit za nemožné a zapovězené, ale naučit se, že vyvolání výjimky, když program data neumí zpracovat je prostě součást protokolu komunikace.
Pokud nějaké službě podstrčím nevalidní data, tak je samozřejmě správně, když zareaguje chybovou hláškou, o tom vůbec není řeč, to je v pořádku a jinak to udělat nejde. Při komunikaci zvnějšku to nikdo za zapovězené neprohlašuje, proč by to dělal?!

Jediný problém je v tom, že unittesty z principu nikdy nemůžou otestovat všechno a tímpádem máš vždycky šanci, že to v produkci spadne (což máš i u té Javy, díky mj. null-u).

Vážně? Pro mě je největší bolest Unicode, překlepy se mi od doby co v editoru používám linter (pep8, pyflakes a pylint) prakticky nestávají.
To taky, ale to je návrhová nedostatečnost Pythonu 2 (vzhledem k době vzniku to nebyla chyba). On to nemusí být překlep typu místo "abcde" napíšu "abcd". Může to být třeba to, že omylem použiješ jinou proměnnou/metodu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 12:05:34
O žádných serverových věcech tazatel nenapsal ani písmeno. To si tam dofantazírovali ostatní zdejší kecálisté a na základě těchto a podobně vykonstruovaných fantasmagorií dospěli k závěru, že Python není vhodný jazyk na větší projekty.
No "větší věc" je skoro vždycky serverová věc. Pokud to není velká desktopová aplikace typu LibreOffice apod., pro kterou by platilo skoro to samý jako pro serverovou aplikaci. Akorát tam pády vadí o trochu míň, protože když to spadne, spadne to jednomu člověku.

Jde o větší projekt? Ano. Je pro něj Python vhodný? Ano. Je tedy pravdivé tvrzení, že se Python k takovým věcem nehodí? Ne.
Q.E.D.
Pro interní projekty, kde se vůbec nic nestane, když to občas spadne, je Python úplně v pohodě. O tom myslím není sporu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 12:16:01
Toto je chybný přístup, IDE jako PyCharm to nedělá, protože neexistuje praktická potřeba to dělat
To jako že když píšu v Pythonu, tak se nestává, že zjistím, že mi nějaká třída narostla a bylo by fajn ji rozdělit?!

Najít v Pythonu, kde všude se používá první část a kde druhá, je peklo.

, jinak IDE jako PyCharm obsahuje gramatiku jazyka a ve spojení například s debuggerem má všechny předpoklady k tomu, aby si typy zjistilo samo a uložilo například do slovníku, nebo formou anotací do zdrojového textu. Není proto těžké udělat plugin, který by to obstaral včetně vazby na refaktoring.
Ale v Pythonu žádné typy zjistit nejde, protože formálně/striktně žádné neexistují, resp. existuje jich nekonečně mnoho. Pokud mám k dispozici možnost vytvářet úplně libovolné objekty s libovolnými atributy, tak vůbec nejde o gramatiku. Maximálně můžu použít nepovinné/volné typové anotace s tím, že jakmile checker narazí na operaci, kterou neumí rozsoudit (např. json.load), tak je typ neznámý na všech místech, kde ta data použiju, minimálně do první anotace. A i když narazím na první anotaci, bude to zase jenom předpoklad - v produkci to pořád klidně může spadnout.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 28. 03. 2016, 12:18:40
Zkus si přečíst sekci Hnutí za dobrý kód z http://www.abclinuxu.cz/blog/bystroushaak/2014/7/python-poznamky

Jinak osobně jsem v pythonu dělal na projektu, který měl přes 40k řádek podle CLOC (tzn bez prázdných řádků, komentářů, docstringů a tak). Nebyl s tím vůbec žádný problém, dělali jsme to ve dvou a šlo to v pohodě. Možná za to mohla microservices architektura, ale prostě žádné hroucení na hlavu se nekonalo. Ani co se týče kódu, ani co se týče výkonu, naopak se to krásně škáluje. Umím si představit, že by to stejným způsobem šlo klidně o řád dál bez nějakého stresu.

IDE nebo jiné nástroje pro Python vám při refaktoringu typicky pomohou mnohem méně než kompilátory moderních staticky typovaných jazyků (a nezmění to ani pokročilejší IDE jako PyCharm). IMO udržovat kód v Pythonu je tedy o dost náročnější (na druhé straně to zřejmě kompenzuje dostatek programátorů).

IDE jako PyCharm obsahuje gramatiku jazyka a ve spojení například s debuggerem má všechny předpoklady k tomu, aby si typy zjistilo samo a uložilo například do slovníku, nebo formou anotací do zdrojového textu. Není proto těžké udělat plugin, který by to obstaral včetně vazby na refaktoring.

Udělat takový plugin je prakticky nemožné, neboť typová rekonstrukce i pro jednoduché typové systémy (jako je například System F) je nerozhodnutelná. A pro (rozumné) otypování netriviálních programů v Pythonu potřebujete mnohem složitější typový systém (hádám minimálně na úrovni DOT).
Z teoretického hlediska to možné není, z praktického ano. Stačí zaznamenat jaké typy proměnné nabývají během běhu programu, a to lze. Bude to empirická typová závislost, která bude poskytovat informaci, které typy proměnné nabývají, nevyloučí však, že jiný typ, z méně často používané větve programu, nebo větve nepokryté testy nenabudou.

Což bude posilovat používání proměnných s danými typy, protože tu informaci při rozvíjení systému budete mít po ruce a IDE vám ji bude napovídat. Když narazíte v programu na jiný typ, budete mít možnost rozhodnout, zda je to chyba, či záměr, ale nedostanete se do situace, kdy typ bude naprosto neznámý.

To je základ filosofie dynamických programovacích systémů, rozhodovat se na základě informací, které jsou v daném čase k dispozici, nepočítat se všemi možnými eventualitami, které mohou nastat ale v praxi nastávají občas, nebo vůbec. Co je důležité, určuje pak praxe provádění programu, což se dynamicky mění, chyby se opravují postupně, opravy vylepšují systém, nevznikají z nich nové chyby, protože opravujete jen to, co aktuálně nefunguje a neřešíte, co by možná mohlo nefungovat, což bývá často zdrojem dalších chyb. Systém je programován tak, aby se uměl z chyby sám zotavit, protože se počítá s tím, že nastanou.

U statických jazyků je to naopak, snažíte se navrhnout systém tak, aby zahrnoval všechny možnosti, nemyslíte na zadní kolečka, což vede k ignorování rizika chyby a když chyba nastane, systém rovnou zkolabuje. Jístota, že systém je napsán správně je vyšší, ale zároveň je vyšší jistota, že sytém někdy bez zjevné příčiny zkolabuje díky tomu, že v něm vznikne neočekávaná chyba.
 
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 12:27:41
ale nedostanete se do situace, kdy typ bude naprosto neznámý.
Jaký typ má fce json.load?

To je základ filosofie dynamických programovacích systémů, rozhodovat se na základě informací, které jsou v daném čase k dispozici
...přičemž ale "v daném čase" znamená "při běhu v produkci". Čili pokud se při běhu v produkci zjistí, že se někde objevil neočekávaný typ, tak to prostě celé spadne.

Systém je programován tak, aby se uměl z chyby sám zotavit, protože se počítá s tím, že nastanou.
To v pythonu prakticky nejde. Respektive kdybych to chtěl udělat dobře, dostanu se do takové složitosti, že by bylo lepší použít jiný jazyk.

U statických jazyků je to naopak, snažíte se navrhnout systém tak, aby zahrnoval všechny možnosti, nemyslíte na zadní kolečka, což vede k ignorování rizika chyby a když chyba nastane, systém rovnou zkolabuje. Jístota, že systém je napsán správně je vyšší, ale zároveň je vyšší jistota, že sytém někdy bez zjevné příčiny zkolabuje díky tomu, že v něm vznikne neočekávaná chyba.
Co to je za nesmysl?! Počítat se všemi eventualitami právě znamená neignorovat riziko chyby, byť sebemíň pravdpodobné. Statický jazyk mě prostě donutí ošetřit všechny eventuality, jinak se prostě nepřeloží. U Pythonu se můžu rozhodnout, že tohle se nikdy nestane, tak to ošetřovat nebudu - a ejhle, v produkci se zjistí, že to občas nastane :)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 28. 03. 2016, 12:35:08
Toto je chybný přístup, IDE jako PyCharm to nedělá, protože neexistuje praktická potřeba to dělat
To jako že když píšu v Pythonu, tak se nestává, že zjistím, že mi nějaká třída narostla a bylo by fajn ji rozdělit?!

Najít v Pythonu, kde všude se používá první část a kde druhá, je peklo.

, jinak IDE jako PyCharm obsahuje gramatiku jazyka a ve spojení například s debuggerem má všechny předpoklady k tomu, aby si typy zjistilo samo a uložilo například do slovníku, nebo formou anotací do zdrojového textu. Není proto těžké udělat plugin, který by to obstaral včetně vazby na refaktoring.
Ale v Pythonu žádné typy zjistit nejde, protože formálně/striktně žádné neexistují, resp. existuje jich nekonečně mnoho. Pokud mám k dispozici možnost vytvářet úplně libovolné objekty s libovolnými atributy, tak vůbec nejde o gramatiku. Maximálně můžu použít nepovinné/volné typové anotace s tím, že jakmile checker narazí na operaci, kterou neumí rozsoudit (např. json.load), tak je typ neznámý na všech místech, kde ta data použiju, minimálně do první anotace. A i když narazím na první anotaci, bude to zase jenom předpoklad - v produkci to pořád klidně může spadnout.
Proč by to v produkci nemohlo spadnout, to, že to spadne je jisté u jakéhokoliv jazyka, důležitější je automatické zotavení po chybě, zaznamenání chyby, její příčiny a následně pak možnost zasáhnout do kódu tak, aby to nenarušilo základní filozofii celého systému, aby to nebyl hack, ale přirozené rozšíření.

Klasická chyba, v xml datech místo čísla je číslo ve formě řetězce, nebo naopak, staticky typovaný přístup vede na spadnutí v produkci, dynamicky typovaný projde, protože se provede automatická konverze.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 12:41:17
Klasická chyba, v xml datech místo čísla je číslo ve formě řetězce, nebo naopak, staticky typovaný přístup vede na spadnutí v produkci, dynamicky typovaný projde, protože se provede automatická konverze.
To je naprostý nesmysl. Ve staticky typovaném jazyce buď dojde k načtení struktury, protože je korektní, nebo je vrácena chybová hodnota - viz http://package.elm-lang.org/packages/elm-lang/core/3.0.0/Json-Decode - dekódování vrací Result - tj buď přesně ty typy, které jsem tam chtěl mít, nebo hodnotu (Err "some error message").

V pythonu dojde k automatické konverzi? Odkdy? A jak fce json.load ví, na co má konvertovat, když jí nedávám žádné schéma?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 28. 03. 2016, 12:53:10
ale nedostanete se do situace, kdy typ bude naprosto neznámý.
Jaký typ má fce json.load?

To je základ filosofie dynamických programovacích systémů, rozhodovat se na základě informací, které jsou v daném čase k dispozici
...přičemž ale "v daném čase" znamená "při běhu v produkci". Čili pokud se při běhu v produkci zjistí, že se někde objevil neočekávaný typ, tak to prostě celé spadne.

Systém je programován tak, aby se uměl z chyby sám zotavit, protože se počítá s tím, že nastanou.
To v pythonu prakticky nejde. Respektive kdybych to chtěl udělat dobře, dostanu se do takové složitosti, že by bylo lepší použít jiný jazyk.

U statických jazyků je to naopak, snažíte se navrhnout systém tak, aby zahrnoval všechny možnosti, nemyslíte na zadní kolečka, což vede k ignorování rizika chyby a když chyba nastane, systém rovnou zkolabuje. Jístota, že systém je napsán správně je vyšší, ale zároveň je vyšší jistota, že sytém někdy bez zjevné příčiny zkolabuje díky tomu, že v něm vznikne neočekávaná chyba.
Co to je za nesmysl?! Počítat se všemi eventualitami právě znamená neignorovat riziko chyby, byť sebemíň pravdpodobné. Statický jazyk mě prostě donutí ošetřit všechny eventuality, jinak se prostě nepřeloží. U Pythonu se můžu rozhodnout, že tohle se nikdy nestane, tak to ošetřovat nebudu - a ejhle, v produkci se zjistí, že to občas nastane :)

jaký typ máfunkce json.load? Má typ struktury nejčastěji načítaných dat. Tady můžete specifikovat pravidla, které to nějakým způsobem redukují. Takže rozpoznáte, zda jde o nehomogenní data, o kterých je dáno, že mají povahu nějakého slovníku, nebo jde o konkrétní strukturu, která se stále opakuje. data získáte během ladění a provádění jednotkových testů a zaznamená je a zpracuje IDE, následně pak použije k nápovědě.

Monitorovat riziko chyby je nesmysl,  lépe je připravit systém na to, že chyba nastane, tedy definovat co nesmí nastat a připravit se na to, když to nastane. To je filozofie dynamických systémů. Kde to není možno aplikovat, tam použijete nějaký statický a automaticky verifikovaný systém, ale těch oblastí je jen velmi málo.

Prezentovat věc, že v produkci chyby nenastanou je lakování reality na růžovo, lepší je mít připravený postup, co dělat, když nastanou. Například opakovat výpočet, chybu ignorovat, doplnit náhradním pravděpodobným výsledkem, spustit nějakou havarijní činnost a podobně.

Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 13:00:13
jaký typ máfunkce json.load? Má typ struktury nejčastěji načítaných dat. Tady můžete specifikovat pravidla, které to nějakým způsobem redukují. Takže rozpoznáte, zda jde o nehomogenní data, o kterých je dáno, že mají povahu nějakého slovníku, nebo jde o konkrétní strukturu, která se stále opakuje. data získáte během ladění a provádění jednotkových testů a zaznamená je a zpracuje IDE, následně pak použije k nápovědě.
Proč zase mateš pojmy?! Prostě json.load žádný typ NEMÁ. Struktura dat, které vrací, je NEZNÁMÁ a NIJAK se nekontroluje, protože se ji NEPŘEDÁVÁ žádné schema.

Hele, já mám Python rád, je to jazyk, který používám jako druhý nejčastější, a myslím, že na některé věci (výuka, jednodušší aplikace) je naprosto skvělý a jsem rád, že se tak rozšířil, ale tyhle lži mu dělají fakt medvědí službu.

Monitorovat riziko chyby je nesmysl,  lépe je připravit systém na to, že chyba nastane, tedy definovat co nesmí nastat a připravit se na to, když to nastane.
Ano, to je filosofie Erlangu. Python pro to ale narozdíl od něj nemá prostředky. Nemá (jednoduše použitelné) procesy, supervisory, monitorování a provázání procesů, neumí restartovat část aplikace po selhání. Čili tohle by šlo, ale NEDĚJE se to. Existují snahy jako např Pykka, ale oproti Akka jí chybí některé zásadní věci, takže je to stejně nepoužitelné.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 28. 03. 2016, 13:04:50
Klasická chyba, v xml datech místo čísla je číslo ve formě řetězce, nebo naopak, staticky typovaný přístup vede na spadnutí v produkci, dynamicky typovaný projde, protože se provede automatická konverze.
To je naprostý nesmysl. Ve staticky typovaném jazyce buď dojde k načtení struktury, protože je korektní, nebo je vrácena chybová hodnota - viz http://package.elm-lang.org/packages/elm-lang/core/3.0.0/Json-Decode - dekódování vrací Result - tj buď přesně ty typy, které jsem tam chtěl mít, nebo hodnotu (Err "some error message").

V pythonu dojde k automatické konverzi? Odkdy? A jak fce json.load ví, na co má konvertovat, když jí nedávám žádné schéma?

Když jednou v xml máte EAN zboží "1231238901560" a jindy od jiného dodavatele ve stejném formátu 1231238901560, tak to chyba v datech není. To jaké typy datům přiřadíte je vnitřní abstrakce programu, a ta by měla být podřízena vnější realitě, takže když program vyhodí chybu, tak to sice není špatně, alespoň se o té chybě ví, ale požadovaná činnost v realitě vlastně neproběhla  a událost je hodnocena jako havárie. Takže program nemá skončit s chybou, ale buď provést automatickou konverzi a nebo danou větu vyřadit ze zpracování, ostatních datových vět se to týkat nemá.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 13:08:55
Když jednou v xml máte EAN zboží "1231238901560" a jindy od jiného dodavatele ve stejném formátu 1231238901560, tak to chyba v datech není. To jaké typy datům přiřadíte je vnitřní abstrakce programu, a ta by měla být podřízena vnější realitě, takže když program vyhodí chybu, tak to sice není špatně, alespoň se o té chybě ví, ale požadovaná činnost v realitě vlastně neproběhla  a událost je hodnocena jako havárie. Takže program nemá skončit s chybou, ale buď provést automatickou konverzi a nebo danou větu vyřadit ze zpracování, ostatních datových vět se to týkat nemá.
Pokud někde chci mít možnost stringu nebo intu, tak ten typ je "string nebo int" a pokud chci, dál si to převedu na jeden z nich. Přesně takhle se to třeba v tom Elmu dělá - viz Decode.oneOf.

Opakuju: jak dělá Python "automatickou konverzi"? Nijak. Nedělá ji. Je to další lež. Pokud chci konverzi, musím si ji tam napsat - tj. projít celou strukturu, ocheckovat všechny typy, převést některé na jiné. Čili úplně přesně totéž jako v tom Elmu, akorát to musím dělat ručně.

Sorry, už mě ta snůška polopravd a lží nebaví, končím.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 28. 03. 2016, 13:27:03
Hele, já mám Python rád, je to jazyk, který používám jako druhý nejčastější, a myslím, že na některé věci (výuka, jednodušší aplikace) je naprosto skvělý a jsem rád, že se tak rozšířil, ale tyhle lži mu dělají fakt medvědí službu.
Jo proto ho používá Dropbox, Google, Reddit, Bitbucket, Pinterest a mohl bych pokračovat... Určitě ho maj jen na výuku a jednodušší aplikace :-)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 13:34:34
Jo proto ho používá Dropbox, Google, Reddit, Bitbucket, Pinterest a mohl bych pokračovat... Určitě ho maj jen na výuku a jednodušší aplikace :-)
Pokud má někdo k dispozici stejné prostředky jako Dropbox nebo Google, tak určitě může Python zvažovat :)

Tenhle argument fakt nesnáším. Že je velká firma schopná něco uchodit neznamená, že to samé zvládne nějaká malá česká firma stejně dobře a že je to pro ni stejně dobrá volba.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 28. 03. 2016, 13:41:40
jaký typ máfunkce json.load? Má typ struktury nejčastěji načítaných dat. Tady můžete specifikovat pravidla, které to nějakým způsobem redukují. Takže rozpoznáte, zda jde o nehomogenní data, o kterých je dáno, že mají povahu nějakého slovníku, nebo jde o konkrétní strukturu, která se stále opakuje. data získáte během ladění a provádění jednotkových testů a zaznamená je a zpracuje IDE, následně pak použije k nápovědě.
Proč zase mateš pojmy?! Prostě json.load žádný typ NEMÁ. Struktura dat, které vrací, je NEZNÁMÁ a NIJAK se nekontroluje, protože se ji NEPŘEDÁVÁ žádné schema.

Hele, já mám Python rád, je to jazyk, který používám jako druhý nejčastější, a myslím, že na některé věci (výuka, jednodušší aplikace) je naprosto skvělý a jsem rád, že se tak rozšířil, ale tyhle lži mu dělají fakt medvědí službu.

Monitorovat riziko chyby je nesmysl,  lépe je připravit systém na to, že chyba nastane, tedy definovat co nesmí nastat a připravit se na to, když to nastane.
Ano, to je filosofie Erlangu. Python pro to ale narozdíl od něj nemá prostředky. Nemá (jednoduše použitelné) procesy, supervisory, monitorování a provázání procesů, neumí restartovat část aplikace po selhání. Čili tohle by šlo, ale NEDĚJE se to. Existují snahy jako např Pykka, ale oproti Akka jí chybí některé zásadní věci, takže je to stejně nepoužitelné.
V realitě json.load datový typ výsledku má, jaký se dá zjistit dynamicky v programu, a tato zjištění statisticky zpracovvávat, může to dělat IDE během ladění a na základě toho poskytovat nápovědu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 28. 03. 2016, 13:44:07
Jo proto ho používá Dropbox, Google, Reddit, Bitbucket, Pinterest a mohl bych pokračovat... Určitě ho maj jen na výuku a jednodušší aplikace :-)
Pokud má někdo k dispozici stejné prostředky jako Dropbox nebo Google, tak určitě může Python zvažovat :)

Tenhle argument fakt nesnáším. Že je velká firma schopná něco uchodit neznamená, že to samé zvládne nějaká malá česká firma stejně dobře a že je to pro ni stejně dobrá volba.
Google s Pythonem začínal v garáži. Dnes by možná začínal s něčím jiným.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Radek Miček 28. 03. 2016, 14:05:08
Zkus si přečíst sekci Hnutí za dobrý kód z http://www.abclinuxu.cz/blog/bystroushaak/2014/7/python-poznamky

Jinak osobně jsem v pythonu dělal na projektu, který měl přes 40k řádek podle CLOC (tzn bez prázdných řádků, komentářů, docstringů a tak). Nebyl s tím vůbec žádný problém, dělali jsme to ve dvou a šlo to v pohodě. Možná za to mohla microservices architektura, ale prostě žádné hroucení na hlavu se nekonalo. Ani co se týče kódu, ani co se týče výkonu, naopak se to krásně škáluje. Umím si představit, že by to stejným způsobem šlo klidně o řád dál bez nějakého stresu.

IDE nebo jiné nástroje pro Python vám při refaktoringu typicky pomohou mnohem méně než kompilátory moderních staticky typovaných jazyků (a nezmění to ani pokročilejší IDE jako PyCharm). IMO udržovat kód v Pythonu je tedy o dost náročnější (na druhé straně to zřejmě kompenzuje dostatek programátorů).

IDE jako PyCharm obsahuje gramatiku jazyka a ve spojení například s debuggerem má všechny předpoklady k tomu, aby si typy zjistilo samo a uložilo například do slovníku, nebo formou anotací do zdrojového textu. Není proto těžké udělat plugin, který by to obstaral včetně vazby na refaktoring.

Udělat takový plugin je prakticky nemožné, neboť typová rekonstrukce i pro jednoduché typové systémy (jako je například System F) je nerozhodnutelná. A pro (rozumné) otypování netriviálních programů v Pythonu potřebujete mnohem složitější typový systém (hádám minimálně na úrovni DOT).
Z teoretického hlediska to možné není, z praktického ano. Stačí zaznamenat jaké typy proměnné nabývají během běhu programu, a to lze.

To sice jde, ale má to několik problémů:

1) Typ jedné proměnné (nebo obocněji výrazu) může záviset na typu nebo hodnotách dalších proměnných (výrazů). Takto zjištěné informace tedy budou mít například tvar: proměnná a mívá typ int, poud b obsahuje hodnotu 3, c obsahuje řetězec "ahoj", d obsahuje hodnotu None atd. Bohužel tato informace o proměnné a nic neříká, když b obsahuje hodnotu 0. Tedy takto získaná informace má velmi malé užití.

2) Může se stát, že tímto způsobem pro některé výrazy odvodíte miliony nebo miliardy možných typů (záleží, co přesně budou typy) - což pro uživatele už příliš užitečné nebude a navíc to bude IDE zpomalovat.

3) Žádné typy nemáte, dokud program nespustíte. Tj. při refaktoringu vám IDE příliš nepomůže, pokud program nejde zrovna spustit.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 28. 03. 2016, 14:13:09
Hele, já mám Python rád, je to jazyk, který používám jako druhý nejčastější, a myslím, že na některé věci (výuka, jednodušší aplikace) je naprosto skvělý a jsem rád, že se tak rozšířil, ale tyhle lži mu dělají fakt medvědí službu.
Jo proto ho používá Dropbox, Google, Reddit, Bitbucket, Pinterest a mohl bych pokračovat... Určitě ho maj jen na výuku a jednodušší aplikace :-)
Jo super, takže když začne FB používat BRAINFUCK pro backend, bude to známka že BRAINFUCK je super pro backend? Nebo maj jen v týmu tobě podobného evangelíka kterej je hotovej z BRAINFUCKu ... ?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 28. 03. 2016, 14:21:03
Jo proto ho používá Dropbox, Google, Reddit, Bitbucket, Pinterest a mohl bych pokračovat... Určitě ho maj jen na výuku a jednodušší aplikace :-)
Pokud má někdo k dispozici stejné prostředky jako Dropbox nebo Google, tak určitě může Python zvažovat :)

Tenhle argument fakt nesnáším. Že je velká firma schopná něco uchodit neznamená, že to samé zvládne nějaká malá česká firma stejně dobře a že je to pro ni stejně dobrá volba.
Budeš se divit, ale i v ČR se python používá. Z těch asi nejznámějších namátkou Seznam, Skypicker, CZ.NIC, Twisto, Websupport...
Jedinej problém je nedostatek kvalitních vývojářů, ale to je problém u jakékoliv profese/jazyka.

Nejsem zaslepenej pythonista, dost věcí mě štve, ale rozhodně je blbost tvrdit že python se hodí tak maximálně na malé/výukové programy a že nic jiného v něm nemá smysl programovat.
Hele, já mám Python rád, je to jazyk, který používám jako druhý nejčastější, a myslím, že na některé věci (výuka, jednodušší aplikace) je naprosto skvělý a jsem rád, že se tak rozšířil, ale tyhle lži mu dělají fakt medvědí službu.
Jo proto ho používá Dropbox, Google, Reddit, Bitbucket, Pinterest a mohl bych pokračovat... Určitě ho maj jen na výuku a jednodušší aplikace :-)
Jo super, takže když začne FB používat BRAINFUCK pro backend, bude to známka že BRAINFUCK je super pro backend? Nebo maj jen v týmu tobě podobného evangelíka kterej je hotovej z BRAINFUCKu ... ?
Jasný nikde netvrdím že je to nejlepší volba, jen píšu že je nesmysl tvrdit že python se hodí maximálně na malé projekty...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: norm 28. 03. 2016, 14:29:28
Jo proto ho používá Dropbox, Google, Reddit, Bitbucket, Pinterest a mohl bych pokračovat... Určitě ho maj jen na výuku a jednodušší aplikace :-)
Pokud má někdo k dispozici stejné prostředky jako Dropbox nebo Google, tak určitě může Python zvažovat :)

Tenhle argument fakt nesnáším. Že je velká firma schopná něco uchodit neznamená, že to samé zvládne nějaká malá česká firma stejně dobře a že je to pro ni stejně dobrá volba.
Budeš se divit, ale i v ČR se python používá. Z těch asi nejznámějších namátkou Seznam, Skypicker, CZ.NIC, Twisto, Websupport...
Jedinej problém je nedostatek kvalitních vývojářů, ale to je problém u jakékoliv profese/jazyka.

Nejsem zaslepenej pythonista, dost věcí mě štve, ale rozhodně je blbost tvrdit že python se hodí tak maximálně na malé/výukové programy a že nic jiného v něm nemá smysl programovat.

Nedostatek není problém. Zkus jako kvalitní vývojář přijít do malé Python firmy a říct si 150 tisíc na HPP. Uvidíš, co ti řeknou. Proto kvalitní vývojáři nebudou ztrácet čas s nějaký jazykem na hraní za 60 tisíc. Proč by to kvalitní vývojář dělal? On je rozdíl udělat si webík s malým backendem a mít obrovskou infrastrukturu. Co třeba architektura? Nemá cenu tu řešit "velké" projekty o pár desítkách tisíc řádků, když nikdo neřekne architekturu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 28. 03. 2016, 14:35:49
Skypicker nedávno spamoval s

Citace
Hello Lishaak,

I am a software engineer and part of the Developer Relations team with source{d}, based in Madrid. We are a rapidly growing startup working on improving developer recruitment. We have analyzed your open source contributions on Github and we think that your experience could be a good fit for the position of Python Backend Engineer with Skypicker.

...

With that in mind, Skypicker is looking for a Python enthusiast willing to join their team in Brno, Czech Republic. You will have a track record with the language ideally with a wide general knowledge on web technologies and a background in data structures, algorithms and software design. Any knowledge of the Bottle framework or experience working with uWSGI, Redshift or real-time systems and ElasticSearch is, of course, a bonus.

Your salary would be between 42.000€ and 80.000€, depending on your experience and skills.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 14:49:42
Budeš se divit, ale i v ČR se python používá. Z těch asi nejznámějších namátkou Seznam, Skypicker, CZ.NIC, Twisto, Websupport...
Nebudu se divit, protože pro jednu z takových firem dělám. Jak jsem byl řekl: desetitisíce řádků.

Jasný nikde netvrdím že je to nejlepší volba, jen píšu že je nesmysl tvrdit že python se hodí maximálně na malé projekty...
Ale to nikdo neřekl. Na malé projekty se hodí perfektně. Na velké projekty je to diskutabilní - je potřeba pečlivě zvážit, jestli to ta konkrétní firma je schopná ustát (kvalita analytiků, programátorů, štábní kultura, kvalita vedení atd.)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 28. 03. 2016, 15:35:26
Budeš se divit, ale i v ČR se python používá. Z těch asi nejznámějších namátkou Seznam, Skypicker, CZ.NIC, Twisto, Websupport...
Nebudu se divit, protože pro jednu z takových firem dělám. Jak jsem byl řekl: desetitisíce řádků.

Jasný nikde netvrdím že je to nejlepší volba, jen píšu že je nesmysl tvrdit že python se hodí maximálně na malé projekty...
Ale to nikdo neřekl. Na malé projekty se hodí perfektně. Na velké projekty je to diskutabilní - je potřeba pečlivě zvážit, jestli to ta konkrétní firma je schopná ustát (kvalita analytiků, programátorů, štábní kultura, kvalita vedení atd.)
10000 řádku je 10 souborů po 1000 řádcích. To není ani malý projekt. Obyčejný eshop má řádově statisíce řádků :-)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 15:39:29
10000 řádku je 10 souborů po 1000 řádcích. To není ani malý projekt. Obyčejný eshop má řádově statisíce řádků :-)
Desetitisíce není deset tisíc. Možná že už to přelezlo do stovek, nevím, mám zajímavější koníčky než to denně kontrolovat :)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 28. 03. 2016, 15:40:02
Skypicker nedávno spamoval s


To neni Skypicker, ale agentura. Až řeknou cenu oni, bude to více přesné.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Kit 28. 03. 2016, 16:09:34
10000 řádku je 10 souborů po 1000 řádcích. To není ani malý projekt. Obyčejný eshop má řádově statisíce řádků :-)

Spíš 100 souborů po 100 řádcích. 1000řádkové zdrojové soubory (resp. skripty) snad nedělá nikdo.

Čím méně řádek má projekt, tím se zpravidla lépe udržuje. Původní Seznam.cz měl prý něco kolem 500 řádek.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: F 28. 03. 2016, 16:27:11
Python je co do počtu řádek docela depresivní. Například jsem dělal zakázku pět měsíců o volném čase (večery, víkendy). Narval jsem do toho docela dost času a je tam spousta funkcionality (vlastní UI widgety, práce s netem, poskytování REST API, propojení na tři další systémy, parsování HTML / XML, generování všemožných formátů a tak). Když jsem si to ale nakonec počítal, tak to mělo podle CLOC jen něco okolo 5k5 aktivních řádků. Sice jsem část kódu v průběhu zrefaktoroval a udělal z nich různé opensource knihovničky, které jsou tam přes závislost package manageru, ale i tak je to docela .. divně málo. V javě jsem běžně napsal tisíce řádků za den a ani se nechumelilo. To ale (časově) nevychází, ani kdybych počítal hustější kód 1:5.

Imho je to tím, že python je do jisté míry glue jazyk, kde toho strašnou spoustu zajišťují již builtin knihovny, či různé opensource věci v package manageru. Například já v tom projektu mám ~20 závislostí.

S tím poměřováním řádků je to potom docela těžké, protože když Prýmek napíše, že je to desítek tisíc, tak asi hádám nepočítá všechny závislosti co tam má. Možná by trochu lepší metrika byl počet commitů, nebo člověkohodin, které na tom strávili.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 16:31:52
S tím poměřováním řádků je to potom docela těžké, protože když Prýmek napíše, že je to desítek tisíc, tak asi hádám nepočítá všechny závislosti co tam má. Možná by trochu lepší metrika byl počet commitů, nebo člověkohodin, které na tom strávili.
Abysme si rozuměli: byla to reakce na to "možná bys neřekl že...". Řekl :) Já na tom kódu nepracuju a ani nechci jít do žádných podrobností. Prostě jenom vím o tom, že větší projekty v Py existují i v ČR, to je celé, víc bych to nerozebíral.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 28. 03. 2016, 16:37:58
V javě jsem běžně napsal tisíce řádků za den a ani se nechumelilo.

To si děláš srandu? :D Tohle si fakt Java nezaslouží. Já mám tak max desítky denně a ty to tam házíš po tisících. Se pak nedivim, že se nadává na Javu, když v tom lidi neumí.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 16:38:32
Pro zajímavost:

Kód: [Vybrat]
find datovka-3.1/ -iname \*.py -exec cat '{}' \; | wc -l
    9832

Datovka 4 už je přepsaná do C++, důvody:
Citace
Proč jsme se rozhodli pro přepis staré Datovky v Pythonu do Qt? Především pro problémy spojené s distribucí a instalací Pythonu pro Windows. Knihovna Qt dovoluje vytvořit grafické uživatelské rozhraní, jehož vzhled se příliš neliší mezi podporovanými OS. Qt navíc dovoluje programování přenositelných vícevláknových aplikací. Použití staticky typovaného jazyka jako je C++ dovoluje odhalit chyby již v době překladu programu. Domníváme se, ze se celkově zlepší přenositelnost, udržovatelnost i testovatelnost této aplikace.
https://blog.nic.cz/2014/12/18/nova-datovka-pro-desktop-rada-novinek/
Název: Re:Python - dobré rady a praktiky
Přispěvatel: gl 28. 03. 2016, 16:49:07
BTW kromě statického typového systému mi v Pythonu chybí podpora pro vytváření neměnných tříd a neměnné kolekce.

Můžete používat namedtuple. Pro perzistentní kolekce existuje https://github.com/tobgu/pyrsistent.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Overload 28. 03. 2016, 17:00:10
Citace
dostávám se do oblasti poněkud dobastlené, bez first-class podpory v jazyce (docela připomíná promises v JS)

Už několikrát jsem si všiml, že o něčem tvrdíte, jak to jde v JS komplikovaně nebo na to není podpora v jazyce a ono to přitom jde poměrně snadno nebo na to podpora v jazyce je. Nebudu to teď dohledávat, ale konkrétně promises podporu mají od ES6 a na nich pak stavějící async/await v ES7. Díky transpilerům obojí použitelné už dnes. Ale to jen tak mimo téma.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 28. 03. 2016, 17:29:13
Skypicker nedávno spamoval s

Citace
Hello Lishaak,

I am a software engineer and part of the Developer Relations team with source{d}, based in Madrid. We are a rapidly growing startup working on improving developer recruitment. We have analyzed your open source contributions on Github and we think that your experience could be a good fit for the position of Python Backend Engineer with Skypicker.

...

With that in mind, Skypicker is looking for a Python enthusiast willing to join their team in Brno, Czech Republic. You will have a track record with the language ideally with a wide general knowledge on web technologies and a background in data structures, algorithms and software design. Any knowledge of the Bottle framework or experience working with uWSGI, Redshift or real-time systems and ElasticSearch is, of course, a bonus.

Your salary would be between 42.000€ and 80.000€, depending on your experience and skills.
Když sem se nedávno o ně zajímal tak tyhle ceny tak nějak seděj, ale v Kč... Aspoň mě to říkal jejich náborář, tak předpokládám že ví víc než agentura skenující github...
Budeš se divit, ale i v ČR se python používá. Z těch asi nejznámějších namátkou Seznam, Skypicker, CZ.NIC, Twisto, Websupport...
Nebudu se divit, protože pro jednu z takových firem dělám. Jak jsem byl řekl: desetitisíce řádků.

Jasný nikde netvrdím že je to nejlepší volba, jen píšu že je nesmysl tvrdit že python se hodí maximálně na malé projekty...
Ale to nikdo neřekl. Na malé projekty se hodí perfektně. Na velké projekty je to diskutabilní - je potřeba pečlivě zvážit, jestli to ta konkrétní firma je schopná ustát (kvalita analytiků, programátorů, štábní kultura, kvalita vedení atd.)
10000 řádku je 10 souborů po 1000 řádcích. To není ani malý projekt. Obyčejný eshop má řádově statisíce řádků :-)
Tak to bych ten obyčejný eshop chtěj docela vidět, respektive jeho funkcionality...
Pro zajímavost:

Kód: [Vybrat]
find datovka-3.1/ -iname \*.py -exec cat '{}' \; | wc -l
    9832

Datovka 4 už je přepsaná do C++, důvody:
Citace
Proč jsme se rozhodli pro přepis staré Datovky v Pythonu do Qt? Především pro problémy spojené s distribucí a instalací Pythonu pro Windows. Knihovna Qt dovoluje vytvořit grafické uživatelské rozhraní, jehož vzhled se příliš neliší mezi podporovanými OS. Qt navíc dovoluje programování přenositelných vícevláknových aplikací. Použití staticky typovaného jazyka jako je C++ dovoluje odhalit chyby již v době překladu programu. Domníváme se, ze se celkově zlepší přenositelnost, udržovatelnost i testovatelnost této aplikace.
https://blog.nic.cz/2014/12/18/nova-datovka-pro-desktop-rada-novinek/
Což sou logické argumenty, psát desktop aplikaci v pythonu s tím, že to bude běhat i na windows sice můžu, ale proboha proč bych to dělal?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 28. 03. 2016, 18:15:54
Citace
Když sem se nedávno o ně zajímal tak tyhle ceny tak nějak seděj, ale v Kč... Aspoň mě to říkal jejich náborář, tak předpokládám že ví víc než agentura skenující github...

V kč? To jako 40k-80k v korunách hrubýho?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 18:26:22
Už několikrát jsem si všiml, že o něčem tvrdíte, jak to jde v JS komplikovaně nebo na to není podpora v jazyce a ono to přitom jde poměrně snadno nebo na to podpora v jazyce je. Nebudu to teď dohledávat, ale konkrétně promises podporu mají od ES6 a na nich pak stavějící async/await v ES7. Díky transpilerům obojí použitelné už dnes. Ale to jen tak mimo téma.
Napsal jsem "bez first-class podpory v jazyce (docela připomíná promises v JS)". Promises jsou věc, která byla do JS přidána teprve nedávno a oproti jazykům, kde se s asynchronními událostmi počítalo předem, se s tím v JS nepracuje nijak zvlášť dobře. Netvrdil jsem, že to v JS není, naopak. Je to tam a je to opruz.

Pokud chcete konkrétní výtku, tak např. se asynchronní události nedají zpátky synchronizovat. Takže nemůžu napsat fci, která by vracela výsledek asynchronní operace. Pro srovnání v Erlangu/Elixiru to jde triviálně.

Nebo jiná výhrada: "Oproti synchronnímu zápisu je výše uvedený zápis pomocí promisů delší a méně přehledný. Navíc jde při řetězení promisů snadno udělat chybu – stačí zapomenout return před druhým voláním getJSON." http://www.abclinuxu.cz/blog/radekm/2015/3/async-a-await-je-krok-spatnym-smerem
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 28. 03. 2016, 18:35:36
Citace
Když sem se nedávno o ně zajímal tak tyhle ceny tak nějak seděj, ale v Kč... Aspoň mě to říkal jejich náborář, tak předpokládám že ví víc než agentura skenující github...

V kč? To jako 40k-80k v korunách hrubýho?
Ano, proto se divím že u tebe to bylo v eurech :-)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 28. 03. 2016, 18:37:25
OMG, oni říkají roční příjem. A protože nevíš daně v každé zemi, tak to asi bude spíš hodně hrubé až nejhrubší.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 28. 03. 2016, 18:51:09
OMG, oni říkají roční příjem. A protože nevíš daně v každé zemi, tak to asi bude spíš hodně hrubé až nejhrubší.
Jistě což nesedí s tím co sem slyšel a četl od jejich náboráře, sedělo by to kdyby to bylo myšleno v Kč a měsíčně...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 28. 03. 2016, 18:53:09
To je zase věc jiná, že Bystroushaak věří pohádkám zahraniční agentury. Taky si nedovedu představit, že bys dostal přes dva miliony. Za Python? To tak ve snu. Možná v Anglii, ale ani tam asi ne :D
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 28. 03. 2016, 18:54:35
Ano, proto se divím že u tebe to bylo v eurech :-)

Jak píše Javaman, je to 40-80k ročně v eurech. To je 3k3 - 6k6€ měsíčně (89-178k korun) nějakého hodně hrubého platu, který se ještě bude různě danit, možná jako příjem ze zahraničí. To mi nepřijde nijak extra přehnané. Sám jsem pracoval pro malý startup za 300kč / hodinu (čistého) a bývalý kolega senior se mi divil, že by to za tyhle částky vůbec nevzal.

Plat 40k kč/měsíc hrubého se mi u Skypickeru fakt nezdá. I v Redhatu začíná práce někde na 50k hrubého / měsíc. Cizí firmy většinou platí podstatně líp, pokud umíš dobře anglicky a jsi ochotný pořádně makat, tak se dají sehnat (django) nabídky ala 6k$/měsíc. Jedna taková se ke mě dostala minulý měsíc.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Overload 28. 03. 2016, 18:55:29
Kód: [Vybrat]
Oproti synchronnímu zápisu je výše uvedený zápis pomocí promisů delší a méně přehledný
Pokud se kód v článku dá zapsat i synchronně, pak na něm buď nic asynchronního není a nemá smysl ho zapisovat jako promise nebo asynchronní je a pak nemá význam psát ho synchronně. Nicméně součástí ES6 jsou i lambdy, takže zápis se dá podstatně zpřehlednit:

Kód: [Vybrat]
getJSON(cfgUrl)
    .then(cfg => getJSON(cfg.dataUrl)
    .then(data => alert(data))
    .catch(e => /* osetrit chybu */);

Celkově mi výhrady v článku(explicitní označování asynchronních funkcí, zapomenutý return(?)) přijdou spíš trochu jako hnidopišství.

Citace
nemůžu napsat fci, která by vracela výsledek asynchronní operace

Mohl bych poprosit o konkrétnější příklad? Takhle popsané mi to připadá právě jako věc řešitelná pomocí generátorů/promises/async+await.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 28. 03. 2016, 19:03:56
Ano, proto se divím že u tebe to bylo v eurech :-)

Jak píše Javaman, je to 40-80k ročně v eurech. To je 3k3 - 6k6€ měsíčně (89-178k korun) nějakého hodně hrubého platu, který se ještě bude různě danit, možná jako příjem ze zahraničí. To mi nepřijde nijak extra přehnané. Sám jsem pracoval pro malý startup za 300kč / hodinu (čistého) a bývalý kolega senior se mi divil, že by to za tyhle částky vůbec nevzal.

Plat 40k kč/měsíc hrubého se mi u Skypickeru fakt nezdá. I v Redhatu začíná práce někde na 50k hrubého / měsíc. Cizí firmy většinou platí podstatně líp, pokud umíš dobře anglicky a jsi ochotný pořádně makat, tak se dají sehnat (django) nabídky ala 6k$/měsíc. Jedna taková se ke mě dostala minulý měsíc.
Říkal mě rozmezí cca 40-80 v kanclu v Brně, je to cca půlrok tuším, proto sem se dál o to nezajímal. V cizině je to klidně za těch 6k jak píšeš, ale skypicker je Česká firmička, proto se i divím že psali v eurech, ale třeba šli do sebe...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 28. 03. 2016, 19:08:11
Ano, proto se divím že u tebe to bylo v eurech :-)

Jak píše Javaman, je to 40-80k ročně v eurech. To je 3k3 - 6k6€ měsíčně (89-178k korun) nějakého hodně hrubého platu, který se ještě bude různě danit, možná jako příjem ze zahraničí. To mi nepřijde nijak extra přehnané. Sám jsem pracoval pro malý startup za 300kč / hodinu (čistého) a bývalý kolega senior se mi divil, že by to za tyhle částky vůbec nevzal.

Plat 40k kč/měsíc hrubého se mi u Skypickeru fakt nezdá. I v Redhatu začíná práce někde na 50k hrubého / měsíc. Cizí firmy většinou platí podstatně líp, pokud umíš dobře anglicky a jsi ochotný pořádně makat, tak se dají sehnat (django) nabídky ala 6k$/měsíc. Jedna taková se ke mě dostala minulý měsíc.

Co je 300,- na hodinu čistého? To je 48 na ŽL? Za to se fakt moc neprogramuje. Nebo je to zase nějaký root přepočet? Čísla jako znám, jen to chce trochu hodit do kontextu.

40 si také nemyslím, ale je rozdíl mezi 40 a třeba 140 :D
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 28. 03. 2016, 19:09:24
Ano, proto se divím že u tebe to bylo v eurech :-)

Jak píše Javaman, je to 40-80k ročně v eurech. To je 3k3 - 6k6€ měsíčně (89-178k korun) nějakého hodně hrubého platu, který se ještě bude různě danit, možná jako příjem ze zahraničí. To mi nepřijde nijak extra přehnané. Sám jsem pracoval pro malý startup za 300kč / hodinu (čistého) a bývalý kolega senior se mi divil, že by to za tyhle částky vůbec nevzal.

Plat 40k kč/měsíc hrubého se mi u Skypickeru fakt nezdá. I v Redhatu začíná práce někde na 50k hrubého / měsíc. Cizí firmy většinou platí podstatně líp, pokud umíš dobře anglicky a jsi ochotný pořádně makat, tak se dají sehnat (django) nabídky ala 6k$/měsíc. Jedna taková se ke mě dostala minulý měsíc.
Říkal mě rozmezí cca 40-80 v kanclu v Brně, je to cca půlrok tuším, proto sem se dál o to nezajímal. V cizině je to klidně za těch 6k jak píšeš, ale skypicker je Česká firmička, proto se i divím že psali v eurech, ale třeba šli do sebe...

Nepsali oni, ale agentura. Skypicker dělají i české agentury a fakt nenabízejí ani sto tisíc :D
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 28. 03. 2016, 19:12:56
Říkal mě rozmezí cca 40-80 v kanclu v Brně, je to cca půlrok tuším, proto sem se dál o to nezajímal. V cizině je to klidně za těch 6k jak píšeš, ale skypicker je Česká firmička, proto se i divím že psali v eurech, ale třeba šli do sebe...

Jo, tak jestli už tam pracuje, tak bych se moc nedivil. Ono obecně ve chvíli, kdy mají nedostatek, tak imho budou nabízet podstatně víc, než když nabírali lidi v dobách, kdy takový hlad neměli. Ale nechci to nějak idealizovat, nebo obhajovat, je to prostě jen informace, co se ke mě dostala jejich spamem.

Citace
Co je 300,- na hodinu čistého? To je 48 na ŽL? Za to se fakt moc neprogramuje. Nebo je to zase nějaký root přepočet? Čísla jako znám, jen to chce trochu hodit do kontextu.

Dohoda o provedení práce.

Nepsali oni, ale agentura. Skypicker dělají i české agentury a fakt nenabízejí ani sto tisíc :D

Tak u české agentury mě to fakt nepřekvapuje. Těžko ale budou lákat lidi ze zahraničí na tohle, což je asi předpokládám účel, když to posílají anglicky a v eurech.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 28. 03. 2016, 19:21:10
OMG, do naší firmy také hledají agentury a na stránkách mají nereálné mzdy. Je mi záhadou, jak to pak zakecají, ale tyhle peníze prostě u nás nedostanou :D Zahraniční agentury jsou obvykle daleko horší, protože když už píšou na východ, tak to berou jen jako blbce z východu a nic moc neřeší. Se mnou se jednou nějaký blbec z Londýna normálně hádal, což jsem ani u českých amatérů nikdy nezažil :D

Takže reálné argumenty jsou spíše nabídky před podpisem a nebo po podpisu. Vše ostatní jsou kecy kolem a plno lidí fakt jen kecá :(

Skypicker vypadá fajn a třeba těch 80 na HPP by tam neměl být problém. Což je na Python hodně slušné, ale neznám nikoho, kdo by tam dělal, tak nevím, jestli tam tolik berou :D
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Radek Miček 28. 03. 2016, 20:09:45
Kód: [Vybrat]
Oproti synchronnímu zápisu je výše uvedený zápis pomocí promisů delší a méně přehledný
Pokud se kód v článku dá zapsat i synchronně, pak na něm buď nic asynchronního není a nemá smysl ho zapisovat jako promise nebo asynchronní je a pak nemá význam psát ho synchronně.

Dělá se to proto, abyste neblokoval vlákno. IMO je to lepší než nechat celou aplikaci v JS zatuhnout, dokud se požadavek nedokončí. Na CLR a JVM jsou zase vlákna drahá.

Citace
explicitní označování asynchronních funkcí

Potíž je, že takto označené funkce nejdou dost dobře používat uvnitř synchronních funkcí. Uvažte například pole promisů přes nějž iterujete pomocí Array.forEach. Kdybyste chtěl jednotlivé promisy postupně asynchroně vykonat (tj. spustit první, počkat až doběhne, spustit druhý, počkat až doběhne, ...) uvnitř forEach, tak to nejde bez zablokování vlákna.

Obecně když byste uvnitř nějaké synchronní funkce chtěl zavolat nějakou asynchronní funkci a počkat na její výsledek, tak to nejde bez zablokování vlákna, což je špatné - lepší by bylo, kdyby se z té synchronní funkce automaticky stala asynchronní a dokázala se vzdát svého vlákna - což se ale nestane.

Zablokování vlákna by samo o sobě nevadilo, kdyby vláken bylo dostatek a byla levná, což na mnoha platformách není - kdyby to tak bylo, tak by se nemuselo zavádět async a await.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 20:10:04
Mohl bych poprosit o konkrétnější příklad? Takhle popsané mi to připadá právě jako věc řešitelná pomocí generátorů/promises/async+await.
Chci napsat funkci mySuperHttpFetcher(), která mi vrátí integer (!!!) zveřejněný na nějaké http adrese. Bez callbacků, bez promisů. Chci prostě
Kód: [Vybrat]

let superNumber = mySuperHttpFetcher()
// superNumber == 42
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Radek Miček 28. 03. 2016, 20:17:32
Citace
nemůžu napsat fci, která by vracela výsledek asynchronní operace

Mohl bych poprosit o konkrétnější příklad? Takhle popsané mi to připadá právě jako věc řešitelná pomocí generátorů/promises/async+await.

Nemůžete napsat synchronní funkci, která by vracela výsledek asynchronní operace bez zablokování vlákna.

Pokud to chcete bez zablokování vlákna, musíte synchronní funkci předělat na asynchronní nebo vedle synchronní udělat asynchronní. Podobná duplikace se například objevuje v Haskellu v modulu Control.Monad, kde je je řada funkcí z modulu List duplikována.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 28. 03. 2016, 20:34:08
nebo asynchronní je a pak nemá význam psát ho synchronně.
To je právě ten omyl pramenící (zřejmě) ze znalostí jazyků, kde asynchronní události synchronizovat nejdou. Proto v JS dochází k tomu peklu callbacků (a promisy to moc nezlepší, jenom mírně změní syntaxi) - věci nejdou synchronizovat a tímpádem jakmile se někde mihne asynchronní událost, probublají promisy nebo callbacky do všeho kódu, který tu fci používá.

V Erlangu se to dělá snadno - volající proces P1 zavolá fci, je pozastavený a čeká na událost. Mezi tím běží ten asynchronní kód v procesu P2 a jakmile je hotovo, pošle P2 zprávu P1, ten ji přijme (typicky zpráva obsahuje výsledek operace) a pokračuje dál.

V JS sice procesy nejsou, ale kdyby to jazyk umožňoval, dalo by se to dělat úplně stejně - první fce je pozastavena *uprostřed*, běží druhá. To ale JS neumožňuje - každá fce musí hned doběhnout. A z toho pramení ten callback hell. Což je přesně pointa toho, co jsem psal - JS je ve vleku toho, že nebyl navržen na to, na co se dneska používá. A promisy na tom vůbec nic nemění.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 28. 03. 2016, 20:44:05
To mě tak napadlo, když jsem se teď díval na nějaký Python příklad. Pokud je nějaké API, tak jak poznáte, co metodám posílat? Z názvu metody?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 28. 03. 2016, 20:51:59
To mě tak napadlo, když jsem se teď díval na nějaký Python příklad. Pokud je nějaké API, tak jak poznáte, co metodám posílat? Z názvu metody?
ehm z dokumentace?...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 28. 03. 2016, 20:53:37
A když není? Protože jinde to mám rovnou u té metody. Dokumentace často není, tak si říkám, jak to asi děláte.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 28. 03. 2016, 21:29:07
A když není? Protože jinde to mám rovnou u té metody. Dokumentace často není, tak si říkám, jak to asi děláte, vrací.
Dokumentace by měla bejt rovnou u konkrétní funkce, kterou si můžeš jednoduše vytisknout pomocí __doc__, tady by si měl mít uvedeno co funkce bere a co dělá, pokud to tam uvedeno není, je to chyba programátora, nikoliv jazyka.
např:
Citace
>>> random.randint.__doc__
'Return random integer in range [a, b], including both end points.\n        '
Nicméně v Pythonu 3.5 to může bejt řešeno (vynuceno) pomocí type hints
Kód: [Vybrat]
def greeting(name: str) -> str:
    return 'Hello ' + name
Z toho je asi hned patrné co do funkce máš rvát a ani tam nic jiného nenarveš.

Pokud dokumentace není, není type hints a není jinak patrné co máš posílat, tak ti nezbude nic jiného než funkci prozkoumat.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 28. 03. 2016, 22:15:22
A když není? Protože jinde to mám rovnou u té metody. Dokumentace často není, tak si říkám, jak to asi děláte, vrací.
Dokumentace by měla bejt rovnou u konkrétní funkce, kterou si můžeš jednoduše vytisknout pomocí __doc__, tady by si měl mít uvedeno co funkce bere a co dělá, pokud to tam uvedeno není, je to chyba programátora, nikoliv jazyka.
např:
Citace
>>> random.randint.__doc__
'Return random integer in range [a, b], including both end points.\n        '
Nicméně v Pythonu 3.5 to může bejt řešeno (vynuceno) pomocí type hints
Kód: [Vybrat]
def greeting(name: str) -> str:
    return 'Hello ' + name
Z toho je asi hned patrné co do funkce máš rvát a ani tam nic jiného nenarveš.

Pokud dokumentace není, není type hints a není jinak patrné co máš posílat, tak ti nezbude nic jiného než funkci prozkoumat.

Tohle je mimochodem situace stejná ve všech běžně používaných jazycích. Jak poznám, co mám strkat do metody v javě? String? No jo, ale co v něm má být? Int? A žere to i nuly? Objekt nějakého typu? A co v něm můžu / nesmím nastavit za properties? Prostě pokud není dokumentace, musí se zkoumat kód.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 28. 03. 2016, 22:20:20
Z toho je asi hned patrné co do funkce máš rvát a ani tam nic jiného nenarveš.

Pokud dokumentace není, není type hints a není jinak patrné co máš posílat, tak ti nezbude nic jiného než funkci prozkoumat.

Což je mimochodem stejné ve všech běžně používaných jazycích. Pokud to není v dokumentaci, tak můžu jen hádat, nebo zkoumat kód. Třeba v Javě, pokud vidím, že metoda bere parametr typu string, nic mi to pořád neříká o tom, jak bude reagovat na konkrétní string. Spadne, když jí dám nulový string? A co když dostane neplatné unicode? A u čísel, co když jí dám nulu? Co když nekonečno, nebo NaN? U objektů null? Pokud není dokumentace, tuhle informaci z typového systému nijak nezjistím a prostě se buď musím kouknout do kódu, nebo to zkusit.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 28. 03. 2016, 22:21:15
Wtf. Prvně to předstírá, že to komentář zahodilo a pak zjistím, že byl vložený. Nový redakční systém ftw.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 28. 03. 2016, 22:48:19
Pokud není dokumentace, tuhle informaci z typového systému nijak nezjistím
To, že má Java hloupý typový systém neznamená, že tuhle informaci z chytrého typového systému nezjistím.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Overload 29. 03. 2016, 07:27:18
Radek, Mirek: Díky za osvětlení. Erlang vypadá opravdu zajímavě. Sice mám rád věci s trochu živější komunitou, ale rozhodně se na něj podívám víc. Mám se ještě co učit.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: fedorac 29. 03. 2016, 08:16:44
Zkus Golang. Soucast jazyka je interface, channel a gorutiny.
Zadny problem s dedicnosti.
Soucasti knihoven je treba HTTP/2 : http://http2.golang.org/gophertiles (http://http2.golang.org/gophertiles)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 08:20:29
Radek, Mirek: Díky za osvětlení. Erlang vypadá opravdu zajímavě. Sice mám rád věci s trochu živější komunitou, ale rozhodně se na něj podívám víc. Mám se ještě co učit.
Doporučil bych spíš http://elixir-lang.org/ - je s Erlangem plně kompatibilní (běží nad stejným VM, má plnou interoperabilitu), je ve spoustě věcí příjemnější (vznikl později a nemá historickou zátěž) a komunita je řekl bych relativně malá, ale extrémně přívětivá.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 29. 03. 2016, 12:12:07
Původně jsem nechtěl do tohoto flamewaru vstupovat. Namísto rad přišly naivní názory javistů, kteří nikdy žádný větší program v Pythonu zřejmě neviděli. Pak je tady pár kritiků poučenějších, jako Radek Miček a Čumil, všechny jejich námitky jsou do jisté míry relevantní, ale nakonec je celý spor v tom, že Python není Java, Scala nebo třeba Haskell. To všichni víme, každý pythonista bez klapek na očích ví, kde jsou přednosti a slabiny jazyka.

Hlavní výhoda Pythonu je ve filosofii "batteries included", snaze o udržení "správné cesty" (deklarace víry, že existuje něco jako správný/nejlepší způsob, jak něco napsat) a v neposlední řadě i v relativně vysoké flexibilitě samotného jazyka. Python je jazyk, který se vyvíjí a handicapy, které jistě má (i mně by se líbilo, kdyby byl více podobný právě Haskellu), poměrně úspěšně řeší (třeba to zmiňované mypy nebo nové typy kolekcí, asyncio apod.). Problémy s rychlostí (jsou-li) řeší FFI, v budoucnu zřejmě čím dál častěji JIT, v klasickém CPythonu je ale holt třeba spoléhat na nízkoúrovňové jazyky.

Takže k věci - pokud chce někdo psát v Pythonu, poradím:

1. Začít s Pythonem 3, dvojku vůbec v pozici začátečníka neuvažovat. Dvojka je umírající platforma a bez ohledu na to, co si kdo myslí o rozhodnutích o změnách 2->3, rozhodnutí prostě padla.

2. Psát kód pořádně, pokud možno od začátku. Na hraní je ipython, jupyter a krátké testovací skriptíky, seriózní projekty mají být psány seriózně, nezanedbávat dokumentaci, vždy mít jasno v tom, co daná metoda/funkce přijímá a vrací a kde končí její pravomoc. To samozřejmě platí o všech jazycích, ale ty dynamické k nekázni svádějí možná o něco více.

3. Nevymýšlet za každou cenu kolo, ale spoléhat se pouze na prověřené a dobře napsané knihovny. Primárně používat standardní knihovnu, v případě potřeby knihovny třetích stran, ale s rozvahou.

4. Snažit se moc nekouzlit, nedělat chytrého, nesnažit se ušetřit pár řádků kódu na úkor čitelnosti, nezakládat si na tom, že umím používat všechny nuance jazyka až nadoraz, když to není potřeba.

S těmito zásadami a v případě týmové práce s rozumným vedením lze v Pythonu rychle a s potěšením napsat hodně rozsáhlé a udržovatelné programy. Python je stabilní platforma s kvalitní dokumentací, dobrou komunitou a spoustou užitečných rad na webu. Samozřejmě existují alternativy, jako třeba Ruby, mně osobně Python sedí více, ale není to jediná možnost. Důrazně doporučuji to s ním alespoň zkusit, i v případě, že se někdo rozhodne pro jiný primární programovací jazyk.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 29. 03. 2016, 13:24:35
...
Tesat do kamene...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 14:28:30
Namísto rad přišly naivní názory javistů, kteří nikdy žádný větší program v Pythonu zřejmě neviděli.

A nebo právě viděli a stačilo jim to.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 29. 03. 2016, 14:31:20
...
Hmm, spousta věcí je prostě obecným principem, a důležitým skillem každého vývojáře. Možná by to chtělo lépe vypíchnout v čem je to v případě Pythonu ve spojení s jeho vlastnostmi ve výsledku tak prospěšné.

Jedna věc je používat jazyk, protože se mi líbí.
Druhá věc je používat jazyk, protože musím (můj případ).
Třetí věc je používat jazyk, protože se to vyplatí.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 29. 03. 2016, 15:12:42
Namísto rad přišly naivní názory javistů, kteří nikdy žádný větší program v Pythonu zřejmě neviděli.

A nebo právě viděli a stačilo jim to.

Zprasit se dá program v každém jazyce. V programování vidět znamená spíš vyzkoušet si se vším všudy, ne přijít k hotovému dílu a pak generalizovat.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 15:31:43
Aha, takže další pohádkář.

Nechceš mi radši poslat link na zdroj na velký projekt, který nevypadá jako kopa hnoje? Ať vidím, jak borci ve skriptovacím jazyce válí.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: ToJeFaktJedno 29. 03. 2016, 15:46:14
Ta představa Javistů, jak z nich Java dělá polobohy, je úsměvná. Neříkám, že touhle nemocí trpí všichni, ale tolik egoismu jako v řadách Javistů těžko jinde pohledat. Jsou tady i nesrovnatelně náročnější a/nebo lepší jazyky a nikdo u toho takhle nevyvádí. To chce klid.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 29. 03. 2016, 15:49:46
...
Hmm, spousta věcí je prostě obecným principem, a důležitým skillem každého vývojáře. Možná by to chtělo lépe vypíchnout v čem je to v případě Pythonu ve spojení s jeho vlastnostmi ve výsledku tak prospěšné.

Jedna věc je používat jazyk, protože se mi líbí.
Druhá věc je používat jazyk, protože musím (můj případ).
Třetí věc je používat jazyk, protože se to vyplatí.

Musíš používat Python, nebo to píšeš obecně?

Co se týče prospěšnosti Pythonu, jak jsem myslím psal, spousta knihoven je přibalena s jazykem rovnou, další jsou snadno k dispozici třeba přes pypi. Pak samozřejmě REPL, resp. jeho větší bratříček IPython notebook, to je úžasná věc, která dosud není úplně samozřejmá. Rychlý runtime, co se týče naběhnutí. Není potřeba uvádět typy, spousta věcí v Pythonu plyne úplně přirozeně, třeba celé číslo není omezeno architekturou procesoru nebo rozhodnutím nějaké komise jako třeba u Javy. Tohle všechno je perfektní výbava pro řešení menších a středních problémů, prototypy apod.

Programovací jazyk je obecně prostředníkem mezi myšlením vývojáře a strojem, na kterém běží výpočet. Čím člověk musí méně ohýbat mozek a soustředit se na detaily výpočtu, tím v zásadě lépe. V Pythonu mám pocit, že se mohu soustředit na problém větší, než v jakémkoliv jiném jazyce.

Sem tam samozřejmě zjišťuju, co je nového v jiných jazycích, zkouším nebo musím něco udělat v něčem jiném, takže celkem přehled mám. Java měla od začátku (jako jazyk), prakticky všechno úplně blbě. Na to, jak dlouho je na světě a co všechno se v té době v oblasti programovacích jazyků odehrálo, se hýbe dopředu moc pomalu. C++ je 100x lepší než před dvaceti lety, až na to, že všechen hnus, co kdysi převzal z C, pořád táhne za sebou. C# je ze staticky typovaného mainstreamu ještě zdaleka nejlepší - jako jazyk. Všechno jsou to ale proti Pythonu strašlivé molochy. Prostě (snad kromě Ruby) vlastně nevím, kde hledat náhradu. Snesl bych Scalu, Haskell, Clojure, ale to už je všechno hodně jiný svět. Erlang/Elixir samozřejmě také.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 29. 03. 2016, 15:52:05
Aha, takže další pohádkář.

Nechceš mi radši poslat link na zdroj na velký projekt, který nevypadá jako kopa hnoje? Ať vidím, jak borci ve skriptovacím jazyce válí.

To bys napřed musel napsat, co u Tebe znamená "nevypadat jako kopa hnoje".
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondrej 29. 03. 2016, 15:55:10
Aha, takže další pohádkář.

Nechceš mi radši poslat link na zdroj na velký projekt, který nevypadá jako kopa hnoje? Ať vidím, jak borci ve skriptovacím jazyce válí.
https://github.com/django/django (https://github.com/django/django)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 15:58:18
Ta představa Javistů, jak z nich Java dělá polobohy, je úsměvná. Neříkám, že touhle nemocí trpí všichni, ale tolik egoismu jako v řadách Javistů těžko jinde pohledat. Jsou tady i nesrovnatelně náročnější a/nebo lepší jazyky a nikdo u toho takhle nevyvádí. To chce klid.

Jestli to nebude třeba složitostí projektů :D Většina běžných programátorů je pro to nevhodná, a proto se nemůžeš divit, že se na ně pohlíží jako na ty horší. Můžou dělat v Pythonu a být v poho, ale větší věci už potřebují víc.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 29. 03. 2016, 16:17:35
Ta představa Javistů, jak z nich Java dělá polobohy, je úsměvná. Neříkám, že touhle nemocí trpí všichni, ale tolik egoismu jako v řadách Javistů těžko jinde pohledat. Jsou tady i nesrovnatelně náročnější a/nebo lepší jazyky a nikdo u toho takhle nevyvádí. To chce klid.



Jestli to nebude třeba složitostí projektů :D Většina běžných programátorů je pro to nevhodná, a proto se nemůžeš divit, že se na ně pohlíží jako na ty horší. Můžou dělat v Pythonu a být v poho, ale větší věci už potřebují víc.

Spíš bych řekl, že si tam tu složitost z velké části uměle vytváříte. Tohle všechno jsou ale kecy. Dej sem odkaz na projekt v Javě, který by v Pythonu nebylo možné rozumně napsat a napiš proč.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 16:17:48
Čím člověk musí méně ohýbat mozek a soustředit se na detaily výpočtu, tím v zásadě lépe. V Pythonu mám pocit, že se mohu soustředit na problém větší, než v jakémkoliv jiném jazyce.
A uměl bys říct, čím to podle tebe je? Co je vlastně to rozhodující, proč je míň náročný? (Nerozporuju to, přijde mi to jako zajímavé téma k diskusi, proč vlastně python tak skvěle uspěl). Rozumím tomu u skriptů a malých jednoúčelových věcí. Tam je Python lepší náhrada Perlu. Pokud se ale bavíme o seriozně vedeném středně velkém projektu, co ušetříš? To šílené OOP modelování musíš dělat stejně jako v jiném jazyce. Takže co vlastně ušetříš? A co získáš? Že nemusíš psát typy? (takže by ti stejnou muziku udělala slušná typová inference?) Nebo že nemusíš psát složené závorky? (tady bezvýhrady souhlas, jestli má Python něco fakt dobře, tak je to syntaxe)

Všechno jsou to ale proti Pythonu strašlivé molochy. Prostě (snad kromě Ruby) vlastně nevím, kde hledat náhradu. Snesl bych Scalu, Haskell, Clojure, ale to už je všechno hodně jiný svět. Erlang/Elixir samozřejmě také.
Těžko říct, jaká molochovitost ti vadí (zase: nerozporuju to). Co Swift? Go? Rust? Je na nich něco molochovitého? Ruby jsi zmínil. Co F#? A jistou dobu (než jsem .NET zavrhl) jsem koketoval s http://boo-lang.org/ - web vypadá srandovně, ale jazyk je to docela fajn.

Myslím, že jazyků je na světě habaděj a podobný Pythonu nenajdeš jenom pokud budeš hledat takový, který bude mít přesně ty vlastnosti, které má Python ;)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 16:20:19
Dej sem odkaz na projekt v Javě, který by v Pythonu nebylo možné rozumně napsat a napiš proč.
To je absurdní požadavek. Dosaď si v té větě za Python Lua...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 29. 03. 2016, 16:24:39
...
Hmm, spousta věcí je prostě obecným principem, a důležitým skillem každého vývojáře. Možná by to chtělo lépe vypíchnout v čem je to v případě Pythonu ve spojení s jeho vlastnostmi ve výsledku tak prospěšné.

Jedna věc je používat jazyk, protože se mi líbí.
Druhá věc je používat jazyk, protože musím (můj případ).
Třetí věc je používat jazyk, protože se to vyplatí.

Musíš používat Python, nebo to píšeš obecně?
Musím používat Python. Ale píšu to obecně.

Co se týče prospěšnosti Pythonu, jak jsem myslím psal, spousta knihoven je přibalena s jazykem rovnou, další jsou snadno k dispozici třeba přes pypi. Pak samozřejmě REPL, resp. jeho větší bratříček IPython notebook, to je úžasná věc, která dosud není úplně samozřejmá. Rychlý runtime, co se týče naběhnutí. Není potřeba uvádět typy, spousta věcí v Pythonu plyne úplně přirozeně, třeba celé číslo není omezeno architekturou procesoru nebo rozhodnutím nějaké komise jako třeba u Javy. Tohle všechno je perfektní výbava pro řešení menších a středních problémů, prototypy apod.
Tak přesně toto je jen popis toho co jazyk dělá, ne v čem se to vyplatí.

Není potřeba uvádět typy,
Tohle bych vůbec nezmiňoval. Je velkej rozdíl mezi tím, že není potřeba uvádět typy, a není možné uvádět typy.
Python a typy jsou vůbec příběh sám o sobě.

Programovací jazyk je obecně prostředníkem mezi myšlením vývojáře a strojem, na kterém běží výpočet. Čím člověk musí méně ohýbat mozek a soustředit se na detaily výpočtu, tím v zásadě lépe. V Pythonu mám pocit, že se mohu soustředit na problém větší, než v jakémkoliv jiném jazyce.
Což je rozhodně pravda. Jenže se to taky dá pochopit značně negativně.

Sem tam samozřejmě zjišťuju, co je nového v jiných jazycích, zkouším nebo musím něco udělat v něčem jiném, takže celkem přehled mám. Java měla od začátku (jako jazyk), prakticky všechno úplně blbě. Na to, jak dlouho je na světě a co všechno se v té době v oblasti programovacích jazyků odehrálo, se hýbe dopředu moc pomalu. C++ je 100x lepší než před dvaceti lety, až na to, že všechen hnus, co kdysi převzal z C, pořád táhne za sebou. C# je ze staticky typovaného mainstreamu ještě zdaleka nejlepší - jako jazyk. Všechno jsou to ale proti Pythonu strašlivé molochy. Prostě (snad kromě Ruby) vlastně nevím, kde hledat náhradu. Snesl bych Scalu, Haskell, Clojure, ale to už je všechno hodně jiný svět. Erlang/Elixir samozřejmě také.
Takže na jednu stranu ty máš přehled, protože jsi vyzkoušel mnoho jazyků, zatímco všichni ti, co tady Python kritizují znají jen Javu? Nepřijde ti to blbí?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 16:27:27
Ta představa Javistů, jak z nich Java dělá polobohy, je úsměvná. Neříkám, že touhle nemocí trpí všichni, ale tolik egoismu jako v řadách Javistů těžko jinde pohledat. Jsou tady i nesrovnatelně náročnější a/nebo lepší jazyky a nikdo u toho takhle nevyvádí. To chce klid.



Jestli to nebude třeba složitostí projektů :D Většina běžných programátorů je pro to nevhodná, a proto se nemůžeš divit, že se na ně pohlíží jako na ty horší. Můžou dělat v Pythonu a být v poho, ale větší věci už potřebují víc.

Spíš bych řekl, že si tam tu složitost z velké části uměle vytváříte. Tohle všechno jsou ale kecy. Dej sem odkaz na projekt v Javě, který by v Pythonu nebylo možné rozumně napsat a napiš proč.

Tak třeba Hadoop. Špičkové řešení, které nemá konkurenci a žádný Python tam nenajdeš, protože tam skriptíky nepotřebují.
https://github.com/apache/hadoop

Trochu staršího infa z Wiki:
Citace
In 2010, Facebook claimed that they had the largest Hadoop cluster in the world with 21 PB of storage.[83] In June 2012, they announced the data had grown to 100 PB[84] and later that year they announced that the data was growing by roughly half a PB per day.[85]

As of 2013, Hadoop adoption had become widespread: more than half of the Fortune 50 used Hadoop.

Tomu říkám větší nasazení.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 29. 03. 2016, 16:29:13
Nebo že nemusíš psát složené závorky? (tady bezvýhrady souhlas, jestli má Python něco fakt dobře, tak je to syntaxe)
Syntaxe dělá hodně. Python má fantastickej syntax suggar ve všem možném. Vůbec bych se nedivil, kdyby to stačilo pro jeho úspěch.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 16:30:37
Tak třeba Hadoop. Špičkové řešení, které nemá konkurenci a žádný Python tam nenajdeš, protože tam skriptíky nepotřebují.
Ale Spark už je ve Scale - a ještě k tomu nad Akka, takže silná inspirace Erlangem ;)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 16:33:48
O Scale se tu nikdo moc nebavil. Nikde nepíšu, že se Scala nedá na nic použít :) Ale pokud bych si měl vybrat mezi Pythonem a Javou... :D
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 16:34:52
Syntaxe dělá hodně. Python má fantastickej syntax suggar ve všem možném. Vůbec bych se nedivil, kdyby to stačilo pro jeho úspěch.
Souhlas. Až na pár zbytečných opruzů, jako třeba že nemůžu napsat
Kód: [Vybrat]
lambda x: if x % 2 == 0 then True else False
ale musím
Kód: [Vybrat]
lambda x: True if x % 2 == 0 else False

Kdyby Python měl filosofii "všechno je výraz", tak by mu to imho prospělo (odstranění returnu u velké části fcí!). Ale chápu datum vzniku pythonu a zároveň Guidovu nesympatii k FP ;)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Kit 29. 03. 2016, 16:57:27
Kód: [Vybrat]
lambda x: True if x % 2 == 0 else False

Chápu, že ve tvém příspěvku jde o něco jiného a uvedená syntaxe mi také připadá nepřirozená, ale také musím:
Kód: [Vybrat]
lambda x: x % 2 == 0
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 17:08:09
Chápu, že ve tvém příspěvku jde o něco jiného a uvedená syntaxe mi také připadá nepřirozená, ale také musím:
Kód: [Vybrat]
lambda x: x % 2 == 0
Čekal jsem, jestli se nějaký hnidopich najde :)) Ale kvituju! Štourat se musí! ;)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: . 29. 03. 2016, 17:31:59
Tak třeba Hadoop. Špičkové řešení, které nemá konkurenci a žádný Python tam nenajdeš, protože tam skriptíky nepotřebují.
https://github.com/apache/hadoop

Trochu staršího infa z Wiki:
Citace
In 2010, Facebook claimed that they had the largest Hadoop cluster in the world with 21 PB of storage.[83] In June 2012, they announced the data had grown to 100 PB[84] and later that year they announced that the data was growing by roughly half a PB per day.[85]

As of 2013, Hadoop adoption had become widespread: more than half of the Fortune 50 used Hadoop.

Tomu říkám větší nasazení.

Když čtu tvou citaci a komentář k ní, na mysl se mi vkrádá pochybnost zda vůbec tušíš co to Hadoop je a k čemu se používá. Na kolik PB diskového prostoru ho FB používá nemá s kvalitou nebo velikostí projektu nic společného.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: . 29. 03. 2016, 17:54:25
V JS sice procesy nejsou, ale kdyby to jazyk umožňoval, dalo by se to dělat úplně stejně - první fce je pozastavena *uprostřed*, běží druhá. To ale JS neumožňuje - každá fce musí hned doběhnout. A z toho pramení ten callback hell. Což je přesně pointa toho, co jsem psal - JS je ve vleku toho, že nebyl navržen na to, na co se dneska používá. A promisy na tom vůbec nic nemění.
To je ale omyl, funkce označená jako generátor uprostřed pozastavit jde. Zápis pomocí generátorů nebo async/await je už velice blízký tomu co by se vám líbilo.

Přijde mi celkem normální, že každému vyhovuje něco jiného. Právě proto máme tolik programovacích jazyků, protože jejich tvůrci měli rozdílné představy o tom, co je nejlepší. Jen mi připadá trochu směšné, pokud tady někteří zarputile trvají na tom, že to jejich je jediné správné (není myšleno přímo na vás).
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 17:59:01
Tak třeba Hadoop. Špičkové řešení, které nemá konkurenci a žádný Python tam nenajdeš, protože tam skriptíky nepotřebují.
https://github.com/apache/hadoop

Trochu staršího infa z Wiki:
Citace
In 2010, Facebook claimed that they had the largest Hadoop cluster in the world with 21 PB of storage.[83] In June 2012, they announced the data had grown to 100 PB[84] and later that year they announced that the data was growing by roughly half a PB per day.[85]

As of 2013, Hadoop adoption had become widespread: more than half of the Fortune 50 used Hadoop.

Tomu říkám větší nasazení.

Když čtu tvou citaci a komentář k ní, na mysl se mi vkrádá pochybnost zda vůbec tušíš co to Hadoop je a k čemu se používá. Na kolik PB diskového prostoru ho FB používá nemá s kvalitou nebo velikostí projektu nic společného.

Přes milion řádků je vlastně takový malý skriptík a že to dokáže takhle velké nasazení, také nic neznamená :D OK.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: . 29. 03. 2016, 18:03:17
Tak třeba Hadoop. Špičkové řešení, které nemá konkurenci a žádný Python tam nenajdeš, protože tam skriptíky nepotřebují.
https://github.com/apache/hadoop

Trochu staršího infa z Wiki:
Citace
In 2010, Facebook claimed that they had the largest Hadoop cluster in the world with 21 PB of storage.[83] In June 2012, they announced the data had grown to 100 PB[84] and later that year they announced that the data was growing by roughly half a PB per day.[85]

As of 2013, Hadoop adoption had become widespread: more than half of the Fortune 50 used Hadoop.

Tomu říkám větší nasazení.

Když čtu tvou citaci a komentář k ní, na mysl se mi vkrádá pochybnost zda vůbec tušíš co to Hadoop je a k čemu se používá. Na kolik PB diskového prostoru ho FB používá nemá s kvalitou nebo velikostí projektu nic společného.

Přes milion řádků je vlastně takový malý skriptík a že to dokáže takhle velké nasazení, také nic neznamená :D OK.
Jestli tady budeš ještě chvíli takhle argumentovat, tak začnu rozumět tomu proč má většina Java programátorů tak špatnou reputaci. Možná by neškodilo si zopakovat základy logiky.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 18:09:03
No a? Přijdu za adminy a tvrděj, jaká je Java sračka. Přijdu za webařema, tvrděj, jaké je Java sračka. Přijdu do startupu, mají Python. Všechno ale jsou lopaty, které nic neumí a pak budou tvrdit o Javě, že je k ničemu. Proto jsem tady, protože Java nikdy špatná nebyla a ani nebude. Proč je teda nejpopulárnější podle TIOBE? Zase nějaký podvod určitě :D Vždyť je dávno mrtvá, ne?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: . 29. 03. 2016, 18:16:02
No a? Přijdu za adminy a tvrděj, jaká je Java sračka. Přijdu za webařema, tvrděj, jaké je Java sračka. Přijdu do startupu, mají Python. Všechno ale jsou lopaty, které nic neumí a pak budou tvrdit o Javě, že je k ničemu. Proto jsem tady, protože Java nikdy špatná nebyla a ani nebude. Proč je teda nejpopulárnější podle TIOBE? Zase nějaký podvod určitě :D Vždyť je dávno mrtvá, ne?
A je ti 14 nebo 15? To by vysvětlovalo, že jste základy logiky ještě nebrali.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 18:17:13
Logika se nedá naučit.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 29. 03. 2016, 18:25:35
Logika se nedá naučit.

Pokud k tomu přistupuješ takhle, tak by to asi lecos vysvětlovalo.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 18:27:01
Třeba co? Pokud někdo má špatné myšlení, nikdy nebude dobrým programátorem. I kdyby měl 50 let praxe. Ani v Pythonu...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondra Satai Nekola 29. 03. 2016, 18:33:11
Třeba co? Pokud někdo má špatné myšlení, nikdy nebude dobrým programátorem. I kdyby měl 50 let praxe. Ani v Pythonu...

To je preci uplne jine tvrzeni, nez ze "logika se neda naucit". Ze to je nesmysl je celkem videt na tom, kdyz vezmes par studentu na zacatku semestru a srovnas je  pak s jejich poucenymi ja na konci semestru...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 29. 03. 2016, 18:33:28
Třeba co? Pokud někdo má špatné myšlení, nikdy nebude dobrým programátorem. I kdyby měl 50 let praxe. Ani v Pythonu...

Tak. A „špatné myšlení“ se pozná podle toho, jestli umí Javu, nebo ne, protože tak jest psáno v knize Javy, kapitola sedm, verš „Javu nepokradeš, hloupému nedáš“.

Slyšeli jsme slovo Javí. Amen.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 18:34:04
Pořád budou dělat stejné chyby.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Lopata 29. 03. 2016, 18:35:54
Vskutku.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 29. 03. 2016, 18:54:20
Ta představa Javistů, jak z nich Java dělá polobohy, je úsměvná. Neříkám, že touhle nemocí trpí všichni, ale tolik egoismu jako v řadách Javistů těžko jinde pohledat. Jsou tady i nesrovnatelně náročnější a/nebo lepší jazyky a nikdo u toho takhle nevyvádí. To chce klid.
No období, kdy Java byla kupa hnoje, má Java už za sebou. Možná to v nich zůstalo a vrací i s úroky to, co se kdysi o Javě psalo :-)))

Nová hvězda na nebi je Julia :-)))
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 19:11:10
Java a kupa hnoje? Tak to období by mě zajímalo.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Sajfi 29. 03. 2016, 19:33:03
Ta představa Javistů, jak z nich Java dělá polobohy, je úsměvná. Neříkám, že touhle nemocí trpí všichni, ale tolik egoismu jako v řadách Javistů těžko jinde pohledat. Jsou tady i nesrovnatelně náročnější a/nebo lepší jazyky a nikdo u toho takhle nevyvádí. To chce klid.
No období, kdy Java byla kupa hnoje, má Java už za sebou. Možná to v nich zůstalo a vrací i s úroky to, co se kdysi o Javě psalo :-)))

Stockholmský syndrom? :-)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 29. 03. 2016, 20:05:32
Dej sem odkaz na projekt v Javě, který by v Pythonu nebylo možné rozumně napsat a napiš proč.
To je absurdní požadavek. Dosaď si v té větě za Python Lua...

Není to absurdní požadavek. Kdybychom se bavili o Lue a chtěl bych ji bránit, zmínil bych Luu a bylo by to úplně relevantní. Javamanova odpověď s Hadoopem a další perly, které mezi tím stačil rozhodit, mi samozřejmě úplně postačily.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: javaman 29. 03. 2016, 20:13:37
To jsem rád a můžu doporučit i dobrou Java literaturu pro začátečníky, abys ten přechod lépe zvládl.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Kit 29. 03. 2016, 20:17:45
To jsem rád a můžu doporučit i dobrou Java literaturu pro začátečníky, abys ten přechod lépe zvládl.

Doporuč raději dobrou literaturu pro Python, o kterém je tady řeč.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 29. 03. 2016, 20:18:08
Co se týče prospěšnosti Pythonu, jak jsem myslím psal, spousta knihoven je přibalena s jazykem rovnou, další jsou snadno k dispozici třeba přes pypi. Pak samozřejmě REPL, resp. jeho větší bratříček IPython notebook, to je úžasná věc, která dosud není úplně samozřejmá. Rychlý runtime, co se týče naběhnutí. Není potřeba uvádět typy, spousta věcí v Pythonu plyne úplně přirozeně, třeba celé číslo není omezeno architekturou procesoru nebo rozhodnutím nějaké komise jako třeba u Javy. Tohle všechno je perfektní výbava pro řešení menších a středních problémů, prototypy apod.
Tak přesně toto je jen popis toho co jazyk dělá, ne v čem se to vyplatí.

Předpokládal jsem, že lidem Tvého rozhledu nemusím vysvětlovat, v čem se vyplatí mít REPL. Nebo proč dopředu typicky nechci mít nutnost řešit, zda se výsledek vejde do 32 nebo 64 bitů. Fakt nechápu, co bych na tom měl ještě vysvětlovat.

Není potřeba uvádět typy,
Tohle bych vůbec nezmiňoval. Je velkej rozdíl mezi tím, že není potřeba uvádět typy, a není možné uvádět typy.
Python a typy jsou vůbec příběh sám o sobě.

Typy už je přece ale možné uvádět, minimálně v deklaraci parametrů a návratové hodnoty funkce. Dokonce se to dá i kontrolovat pomocí mypy. Není to kdoví co, ale je to cesta.

Programovací jazyk je obecně prostředníkem mezi myšlením vývojáře a strojem, na kterém běží výpočet. Čím člověk musí méně ohýbat mozek a soustředit se na detaily výpočtu, tím v zásadě lépe. V Pythonu mám pocit, že se mohu soustředit na problém větší, než v jakémkoliv jiném jazyce.
Což je rozhodně pravda. Jenže se to taky dá pochopit značně negativně.

Až se FP stane mainstreamem (což by se mi i líbilo), dám Ti zapravdu.

Takže na jednu stranu ty máš přehled, protože jsi vyzkoušel mnoho jazyků, zatímco všichni ti, co tady Python kritizují znají jen Javu? Nepřijde ti to blbí?

Tady se zřejmě nechápeme. Poučenou kritiku Pythonu rozhodně vítám a netvrdím, že Ty, M. Prýmek a spol. neznáte nic než Python. Snažil jsem se vypořádat s potenciální radou opustit Python a hledat jinde, resp. vysvětlit, proč jsem, kde jsem, z hlediska hlavního prog. jazyka.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 21:05:40
Není to absurdní požadavek. Kdybychom se bavili o Lue a chtěl bych ji bránit, zmínil bych Luu a bylo by to úplně relevantní.
Ta absurdnost je v tom, že přestože v Lua jde napsat úplně cokoli, i megavelký projekt, nikdo soudný to dělat nebude, protože k tomu není racionální důvod.

Javamanova odpověď s Hadoopem a další perly, které mezi tím stačil rozhodit, mi samozřejmě úplně postačily.
Ono to není tak strašný, jak se všichni tváříte. To opravdu JE velký projekt a JE nasazovaný na vážné problémy. Já osobně neznám pythonský projekt podobného rozsahu a nasazení. Jestli ho někdo zná, rád se nechám poučit. (Jasně, je tady Django, ok)

Že se v Hadoopu zpracovávají data po chuncích, takže je (potenciálně) nasaditelný na libovolné množství dat, nerozhoduje. Ono nejde jenom o ty mapy, shuffly a reducy, ale o všechen ten cirkus kolem. Osobně si nedokážu představit totéž v Pythonu, minimálně kvůli jeho slabé podpoře multithreadingu. Když nic, bylo by to dost pravděpodobně pekelně pomalé.

A když už jsme u toho data science, to byl od tebe taky trochu zavádějící argument. Python imho nebyl použitý proto, že by se na to nějak extra hodil, ale proto, že je populární. Tak se našrouboval na věc, na kterou se (mimochodem) moc nehodí. Nejenom, že nedělá nic víc než lepidlo, to by ještě bylo ok, ale v některých věcech je vyloženě brzda (opět GIL, že...). Takže to se zavede python jako "jazyk na vědecké výpočty" a pak se složitě přemýšlí, jak v C++ backendu hackovat releasování GILu, aby to vůbec bylo k něčemu... Nicméně, abych byl korektní, Rko na tom není o zas tak moc líp - paralelizace tam taky pořádná není a řeší se paralelním spouštěním oddělených interpreterů (snow apod.)

Prostě, tohle vlákno je úplně naprd. Místo abyste se chovali jako dospělí a vedli konstruktivní debatu o tom, co se vám v jakém jazyce líbí a na co se vám neosvědčil, začnete trapnej flejm plnej polopravd z obou stran...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 21:10:54
Tak se našrouboval na věc, na kterou se (mimochodem) moc nehodí.
...a abych předešel dotazu na konrétní příklad: Python striktně vyžaduje evaluaci argumentů fce a nedá se to nijak obejít. A to je např. pro předávání formulí fakt problém. Stejně tak třeba selekce je omezená tím, co v pythonu jde (iloc) a kdyby byl od začátku navržený na vědecké výpočty, uměl by některé věci, které teď neumí, protože na to prostě není určený, jenom byl chytře ohnut, aby v dané oblasti mohl dělat lepidlo.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 29. 03. 2016, 21:21:42
Čím člověk musí méně ohýbat mozek a soustředit se na detaily výpočtu, tím v zásadě lépe. V Pythonu mám pocit, že se mohu soustředit na problém větší, než v jakémkoliv jiném jazyce.
A uměl bys říct, čím to podle tebe je? Co je vlastně to rozhodující, proč je míň náročný? (Nerozporuju to, přijde mi to jako zajímavé téma k diskusi, proč vlastně python tak skvěle uspěl). Rozumím tomu u skriptů a malých jednoúčelových věcí. Tam je Python lepší náhrada Perlu. Pokud se ale bavíme o seriozně vedeném středně velkém projektu, co ušetříš? To šílené OOP modelování musíš dělat stejně jako v jiném jazyce. Takže co vlastně ušetříš? A co získáš? Že nemusíš psát typy? (takže by ti stejnou muziku udělala slušná typová inference?) Nebo že nemusíš psát složené závorky? (tady bezvýhrady souhlas, jestli má Python něco fakt dobře, tak je to syntaxe)

Rozdíl mezi Pythonem a Perlem vidím v tom, že Perl je spíše DSL (jak ostatně trochu plyne z jeho názvu) a Perl GPL. Syntaxe je jedna věc, druhá je lehkost používání základní knihovny, ten pocit, že všechno máš v hlavě a víš kam sáhnout. Jasně, je to věc zvyku, ale v Pythonu mám pocit, že prostě chtěli, aby to bylo co nejjednodušší. Žádný
BufferedReader a FileReader, dám open() a je to. Tím OOP a modelováním lze s úspěchem šetřit a to i u větších projektů (třeba zmiňovaný namedtuple je myslím často dostatečný). Dynamické vlastnosti jazyka se dají taktéž používat ad libitum i ve větších projektech, byť se v tomto snažím krotit sebe i kolegy.

A teď k typové inferenci - to je věc, která ještě poměrně nedávno byla výsadou pár "podivných" jazyků z rodiny ML. Je jasné, že se jazyky navzájem inspirují nebo alespoň nalézají cesty k řešení problémů, které ten jiný jazyk nebo paradigma obratně vyřešily, zatímco ten náš jazyk se tvářil, že problém neexistuje.

Všechno jsou to ale proti Pythonu strašlivé molochy. Prostě (snad kromě Ruby) vlastně nevím, kde hledat náhradu. Snesl bych Scalu, Haskell, Clojure, ale to už je všechno hodně jiný svět. Erlang/Elixir samozřejmě také.
Těžko říct, jaká molochovitost ti vadí (zase: nerozporuju to). Co Swift? Go? Rust? Je na nich něco molochovitého? Ruby jsi zmínil. Co F#? A jistou dobu (než jsem .NET zavrhl) jsem koketoval s http://boo-lang.org/ - web vypadá srandovně, ale jazyk je to docela fajn.

Myslím, že jazyků je na světě habaděj a podobný Pythonu nenajdeš jenom pokud budeš hledat takový, který bude mít přesně ty vlastnosti, které má Python ;)

Molochovitostí myslím faktickou závislostí na IDE, na těžkopádném VM, monstrech typu Maven a tak. Rust a Swift jsou podle mne (coby jazyky) docela na dobré cestě, F# prakticky neznám, tam mi nevoní Mono (to samé tudíž C# i Boo), jinak by mě mohl celkem bavit. Go mi přijde trochu šité příliš na míru dobovým potřebám Google.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 21:35:39
ale v Pythonu mám pocit, že prostě chtěli, aby to bylo co nejjednodušší. Žádný
BufferedReader a FileReader, dám open() a je to.
Jo, tomu rozumím. Jenom si nejsem jistý, jestli to není tak trochu mazání medu kolem úst. Jestli to není tak trochu tak, že právě v těch malých věcech si vystačíš s open(..).read(), ale pak postupně zjišťuješ, že občas potřebuješ řešit velký soubory, na který už se to nehodí a chce to nějak inteligentně chunkovat, tak šáhneš po nějaké knihovně, která to umí, ... a seš tam, kde bys byl stejně ;)  (o tomhle nechci nějak dlouhosáhle diskutovat, je to jenom tak k zamšlení, mám takový dojem, ne vyloženě vyfutrovaný argumenty...)

Tím OOP a modelováním lze s úspěchem šetřit a to i u větších projektů (třeba zmiňovaný namedtuple je myslím často dostatečný).
To je podobný případ. Já považuju namedtuple za super na víceméně funkcionální kód. Ale rozumné OOP s tím neuděláš. Pokud do něj budeš chtít jít (což u většího projektu budeš), seš zas zpátky...

A teď k typové inferenci - to je věc, která ještě poměrně nedávno byla výsadou pár "podivných" jazyků z rodiny ML.
Plusminus asi jo. Ale teď už to tak není a tím ta výhodnost sexy stručnosti pythonu trochu mizí - jinde už ji (teď) máš taky a bez toho, abys obětoval typový systém...

Molochovitostí myslím faktickou závislostí na IDE, na těžkopádném VM, monstrech typu Maven a tak. Rust a Swift jsou podle mne (coby jazyky) docela na dobré cestě, F# prakticky neznám, tam mi nevoní Mono (to samé tudíž C# i Boo), jinak by mě mohl celkem bavit. Go mi přijde trochu šité příliš na míru dobovým potřebám Google.
Chápu. No když vyřadíš "molochy" jako NET a JVM (F#, C#, Java, Scala, Clojure,...), tak ti moc rozumných jazyků nezbude, to je celkem nasnadě :)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 29. 03. 2016, 21:43:41
Není to absurdní požadavek. Kdybychom se bavili o Lue a chtěl bych ji bránit, zmínil bych Luu a bylo by to úplně relevantní.
Ta absurdnost je v tom, že přestože v Lua jde napsat úplně cokoli, i megavelký projekt, nikdo soudný to dělat nebude, protože k tomu není racionální důvod.

Racionální důvod k použití nějaké techologie je, že zavedený tým ji ovládá. Má-li firma samé javisty, nebude inklinovat k použití Pythonu a naopak.

Javamanova odpověď s Hadoopem a další perly, které mezi tím stačil rozhodit, mi samozřejmě úplně postačily.
Ono to není tak strašný, jak se všichni tváříte. To opravdu JE velký projekt a JE nasazovaný na vážné problémy. Já osobně neznám pythonský projekt podobného rozsahu a nasazení. Jestli ho někdo zná, rád se nechám poučit. (Jasně, je tady Django, ok)

Že se v Hadoopu zpracovávají data po chuncích, takže je (potenciálně) nasaditelný na libovolné množství dat, nerozhoduje. Ono nejde jenom o ty mapy, shuffly a reducy, ale o všechen ten cirkus kolem. Osobně si nedokážu představit totéž v Pythonu, minimálně kvůli jeho slabé podpoře multithreadingu. Když nic, bylo by to dost pravděpodobně pekelně pomalé.

Co je těžkého k pochopení toho, že jsme se původně bavili o aplikačním programování a ne o věcech typu Hadoop? Nikdo rozumný ve flame Python versus C nerozporuje, že psát Postgres v Pythonu je nesmysl. A nikdo rozumný nebude mlátit Pythonisty Postgresem.

A když už jsme u toho data science, to byl od tebe taky trochu zavádějící argument. Python imho nebyl použitý proto, že by se na to nějak extra hodil, ale proto, že je populární. Tak se našrouboval na věc, na kterou se (mimochodem) moc nehodí. Nejenom, že nedělá nic víc než lepidlo, to by ještě bylo ok, ale v některých věcech je vyloženě brzda (opět GIL, že...). Takže to se zavede python jako "jazyk na vědecké výpočty" a pak se složitě přemýšlí, jak v C++ backendu hackovat releasování GILu, aby to vůbec bylo k něčemu... Nicméně, abych byl korektní, Rko na tom není o zas tak moc líp - paralelizace tam taky pořádná není a řeší se paralelním spouštěním oddělených interpreterů (snow apod.)

Tohle se mi ani nechce moc rozebírat. Mohli použít třeba tu Javu, ta je ještě populárnější, ne?

Prostě, tohle vlákno je úplně naprd. Místo abyste se chovali jako dospělí a vedli konstruktivní debatu o tom, co se vám v jakém jazyce líbí a na co se vám neosvědčil, začnete trapnej flejm plnej polopravd z obou stran...

Ve vší úctě, nevím, kdo Tě tady udělal soudcem vlákna. Původní autor se ptal na nejlepší praktiky v Pythonu s tím, že bude nastupovat do už existujícího většího projektu v Pythonu a hned první odpověď je od joudy, který neumí nic lepšího, než napsat, že Python je na... Já jsem, pokud sis nevšimnul, napsal aspoň pár rad k věci (jako jeden z mála) a cítil jsem potřebu ty kraviny hejtrů trochu zkorigovat.

Pokud tedy hodláš pokračovat v debatě v tomto duchu, já už Ti odpovídat nebudu. To ale neznamená, že jsi to teď zastavil komplet.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 29. 03. 2016, 21:53:05
Racionální důvod k použití nějaké techologie je, že zavedený tým ji ovládá. Má-li firma samé javisty, nebude inklinovat k použití Pythonu a naopak.
Možná. Anebo taky ne a racionálnější je vybrat super nástroj a nechat lidi si ho osvojit... https://medium.com/@cameronp/the-best-way-to-build-a-dev-team-go-where-the-devs-aren-t-d3f226cfe749#.boy9f5nx6
Ono totiž když máš tým pythonistů, kteří použijí python na něco, na co vůbec není vhodný, jenom protože ho znají, úspěch z toho imho moc nekouká...

Co je těžkého k pochopení toho, že jsme se původně bavili o aplikačním programování a ne o věcech typu Hadoop?
OP neřekl, o jakou oblast mu jde. A jediném, o čem je spor, je vhodnost pythonu na střední a velké projekty.

Tohle se mi ani nechce moc rozebírat. Mohli použít třeba tu Javu, ta je ještě populárnější, ne?
Nemohli, protože Java je jako glue jazyk naprosto nevhodná (kromě toho, že má tytéž zmíněný problémy jako Python). Osobně bych byl radši, kdyby se pro sci rozšířila Julia než Python. Když už teda chceme mermomoci Fortran, C a Rko něčím nahrazovat...

Ve vší úctě, nevím, kdo Tě tady udělal soudcem vlákna.
Nikdo. Nesoudím, říkám svůj názor. A proti korekcím nic nemám, jenom ničemu moc nepomůžou, když jsou ustřelené zase druhým směrem :) Neber si to prosím osobně.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 29. 03. 2016, 22:22:09
Co se týče prospěšnosti Pythonu, jak jsem myslím psal, spousta knihoven je přibalena s jazykem rovnou, další jsou snadno k dispozici třeba přes pypi. Pak samozřejmě REPL, resp. jeho větší bratříček IPython notebook, to je úžasná věc, která dosud není úplně samozřejmá. Rychlý runtime, co se týče naběhnutí. Není potřeba uvádět typy, spousta věcí v Pythonu plyne úplně přirozeně, třeba celé číslo není omezeno architekturou procesoru nebo rozhodnutím nějaké komise jako třeba u Javy. Tohle všechno je perfektní výbava pro řešení menších a středních problémů, prototypy apod.
Tak přesně toto je jen popis toho co jazyk dělá, ne v čem se to vyplatí.

Předpokládal jsem, že lidem Tvého rozhledu nemusím vysvětlovat, v čem se vyplatí mít REPL. Nebo proč dopředu typicky nechci mít nutnost řešit, zda se výsledek vejde do 32 nebo 64 bitů. Fakt nechápu, co bych na tom měl ještě vysvětlovat.
Drtivá většina jazyků, které znám, a které jsem používal a používám tak REPL, nebo implementačně nezávislou velikost čísla mají. A jsou zcela jiné oproti Pythonu.

Jestli to u tebe skončí jako v jiných případech, že prostě Python má spešl filozofii, kterou musíš pochopit, a ohromě ti pomůže při vyvoji, ale nepovím ti jakou ani jak - tak mě naštveš.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: čumil 29. 03. 2016, 23:03:33
Já tak trošku nechápu proč jebete do Mirka. On do týhle diskuze opravdu může dost přinést, sice co se týče FP (tady nerelevantní) bych si dovolil jeho názory zpochybňovat na základě naší minulé diskuze (pure?impure haskell), v téhle doméně je ale nezpochybnitelný pán opravdu on, takže si nemyslím že je dvakrát chytré to strhávat do napadání místo snahy po přiučení se...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: pavlix 29. 03. 2016, 23:14:36
Já tak trošku nechápu proč jebete do Mirka. On do týhle diskuze opravdu může dost přinést, sice co se týče FP (tady nerelevantní) bych si dovolil jeho názory zpochybňovat na základě naší minulé diskuze (pure?impure haskell), v téhle doméně je ale nezpochybnitelný pán opravdu on, takže si nemyslím že je dvakrát chytré to strhávat do napadání místo snahy po přiučení se...

Jsou lidé, kteří si o to prostě říkají.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 30. 03. 2016, 07:30:51
Já tak trošku nechápu proč jebete do Mirka. On do týhle diskuze opravdu může dost přinést, sice co se týče FP (tady nerelevantní) bych si dovolil jeho názory zpochybňovat na základě naší minulé diskuze (pure?impure haskell), v téhle doméně je ale nezpochybnitelný pán opravdu on, takže si nemyslím že je dvakrát chytré to strhávat do napadání místo snahy po přiučení se...

Zatím neřekl (v diskusi se mnou, neříkám, že jeho fungování na tomto fóru není podnětné) nic, co bych nevěděl. A já jsem dost starý na to, abych se tu nechal okřikovat. Tohle si prosím vem osobně.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 30. 03. 2016, 07:53:47
Drtivá většina jazyků, které znám, a které jsem používal a používám tak REPL, nebo implementačně nezávislou velikost čísla mají. A jsou zcela jiné oproti Pythonu.

Python není jediný, to jsem snad netvrdil. Tvrdil jsem, že Python má tyhle "vymoženosti", že má i jiné příjemné vlastnosti, které nemá třeba Java a jiné mainstreamové jazyky. Tvoji argumentaci nechápu.

Jestli to u tebe skončí jako v jiných případech, že prostě Python má spešl filozofii, kterou musíš pochopit, a ohromě ti pomůže při vyvoji, ale nepovím ti jakou ani jak - tak mě naštveš.

Tady mi vkládáš do úst něco, co jsem rozhodně netvrdil. Psal jsem, že u psaní Pythonu mám pocit, že musím méně přizpůsobovat myšlení jazyku a mohu se soustředit na problém, než u jiných jazyků, které jsem zkoušel. Pokud má Python něco jako filosofii, je to PEP 20, který jsem tady rozhodně neuváděl.

Používej si co chceš, já jsem sem přišel se svědectvím, proč u Pythonu zůstávám já, přestože pokukuju jinam a rád bych přešel na jiný jazyk. Protože Python není ani nejrychlejší ani nejchytřejší jazyk nebo platforma. Jenže se s ním dobře dělá (osobní zkušenost, jak to mám asi popsat), má spoustu knihoven, fajn komunitu se spoustou zkušeností atd.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 30. 03. 2016, 08:22:48
Racionální důvod k použití nějaké techologie je, že zavedený tým ji ovládá. Má-li firma samé javisty, nebude inklinovat k použití Pythonu a naopak.
Možná. Anebo taky ne a racionálnější je vybrat super nástroj a nechat lidi si ho osvojit... https://medium.com/@cameronp/the-best-way-to-build-a-dev-team-go-where-the-devs-aren-t-d3f226cfe749#.boy9f5nx6
Ono totiž když máš tým pythonistů, kteří použijí python na něco, na co vůbec není vhodný, jenom protože ho znají, úspěch z toho imho moc nekouká...

Tady se dobýváš do otevřených dveří. Já v legraci klukům u nás v práci říkám každou chvíli, že něco přepíšeme do Haskellu. Na druhou stranu ale změna platformy musí být opravdu signifikantně výhodnější, aby takové rozhodnutí padlo.

Co je těžkého k pochopení toho, že jsme se původně bavili o aplikačním programování a ne o věcech typu Hadoop?
OP neřekl, o jakou oblast mu jde. A jediném, o čem je spor, je vhodnost pythonu na střední a velké projekty.

To je ale pak diskuse k ničemu. Velký projekt je třeba i linuxové jádro a nikdo ho nechce psát v Pythonu. Rozumná diskuse má dojít k poznání, kde jsou konkrétnější hranice použitelnosti či vhodnosti. Generální - blbý výrok, že Python není vhodný na větší projekty (pokud nebyl vyřčen obecně, tak mě klidně oprav) není možno hájit tím, že vyberu jeden konkrétní projekt z domény, u které je každému jasné, že se do ní Python vůbec netlačí.

Tohle se mi ani nechce moc rozebírat. Mohli použít třeba tu Javu, ta je ještě populárnější, ne?
Nemohli, protože Java je jako glue jazyk naprosto nevhodná (kromě toho, že má tytéž zmíněný problémy jako Python). Osobně bych byl radši, kdyby se pro sci rozšířila Julia než Python. Když už teda chceme mermomoci Fortran, C a Rko něčím nahrazovat...

K Julii - ta se vůbec netají tím, že se tlačí na pozici Pythonu v dané doméně. Mně se docela líbí, proč ne. Dosud není ani ve verzi 1, když se začal prosazovat Python v této oblasti, tak snad ani neexistovala. Proč je Python často oblíbenější než R nebo, nedej Bože, C, to se mi opět rozebírat nechce. Skoro začínám mít dojem, že se snažíš Python shazovat za každou cenu - napřed přizvukuješ trollujícím javistům a pak se divíš, proč někdo chce "mermomocí" v tomto století dát pro určitý typ vědeckých výpočtů přednost Pythonu před C nebo Fortranem...

Ve vší úctě, nevím, kdo Tě tady udělal soudcem vlákna.
Nikdo. Nesoudím, říkám svůj názor. A proti korekcím nic nemám, jenom ničemu moc nepomůžou, když jsou ustřelené zase druhým směrem :) Neber si to prosím osobně.
[/quote]

Pokud máš pocit, že píšu něco špatně, klidně mě oprav. Bohužel ale nemám u Tebe také zrovna pocit, že bys vždycky diskutoval férově a snažil se dojít k pravdivému výsledku padni komu padni. Viz výše.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 30. 03. 2016, 09:01:30
Racionální důvod k použití nějaké techologie je, že zavedený tým ji ovládá. Má-li firma samé javisty, nebude inklinovat k použití Pythonu a naopak.
Možná. Anebo taky ne a racionálnější je vybrat super nástroj a nechat lidi si ho osvojit... https://medium.com/@cameronp/the-best-way-to-build-a-dev-team-go-where-the-devs-aren-t-d3f226cfe749#.boy9f5nx6
Ono totiž když máš tým pythonistů, kteří použijí python na něco, na co vůbec není vhodný, jenom protože ho znají, úspěch z toho imho moc nekouká...

Tady se dobýváš do otevřených dveří. Já v legraci klukům u nás v práci říkám každou chvíli, že něco přepíšeme do Haskellu. Na druhou stranu ale změna platformy musí být opravdu signifikantně výhodnější, aby takové rozhodnutí padlo.

Co je těžkého k pochopení toho, že jsme se původně bavili o aplikačním programování a ne o věcech typu Hadoop?
OP neřekl, o jakou oblast mu jde. A jediném, o čem je spor, je vhodnost pythonu na střední a velké projekty.

To je ale pak diskuse k ničemu. Velký projekt je třeba i linuxové jádro a nikdo ho nechce psát v Pythonu. Rozumná diskuse má dojít k poznání, kde jsou konkrétnější hranice použitelnosti či vhodnosti. Generální - blbý výrok, že Python není vhodný na větší projekty (pokud nebyl vyřčen obecně, tak mě klidně oprav) není možno hájit tím, že vyberu jeden konkrétní projekt z domény, u které je každému jasné, že se do ní Python vůbec netlačí.

Tohle se mi ani nechce moc rozebírat. Mohli použít třeba tu Javu, ta je ještě populárnější, ne?
Nemohli, protože Java je jako glue jazyk naprosto nevhodná (kromě toho, že má tytéž zmíněný problémy jako Python). Osobně bych byl radši, kdyby se pro sci rozšířila Julia než Python. Když už teda chceme mermomoci Fortran, C a Rko něčím nahrazovat...

K Julii - ta se vůbec netají tím, že se tlačí na pozici Pythonu v dané doméně. Mně se docela líbí, proč ne. Dosud není ani ve verzi 1, když se začal prosazovat Python v této oblasti, tak snad ani neexistovala. Proč je Python často oblíbenější než R nebo, nedej Bože, C, to se mi opět rozebírat nechce. Skoro začínám mít dojem, že se snažíš Python shazovat za každou cenu - napřed přizvukuješ trollujícím javistům a pak se divíš, proč někdo chce "mermomocí" v tomto století dát pro určitý typ vědeckých výpočtů přednost Pythonu před C nebo Fortranem...

Ve vší úctě, nevím, kdo Tě tady udělal soudcem vlákna.
Nikdo. Nesoudím, říkám svůj názor. A proti korekcím nic nemám, jenom ničemu moc nepomůžou, když jsou ustřelené zase druhým směrem :) Neber si to prosím osobně.

Pokud máš pocit, že píšu něco špatně, klidně mě oprav. Bohužel ale nemám u Tebe také zrovna pocit, že bys vždycky diskutoval férově a snažil se dojít k pravdivému výsledku padni komu padni. Viz výše.
[/quote]
Linuxové jádro by šlo velice dobře napsat i v Pythonu, jen byste potřeboval vhodný optimalizovaný překladač Pythonu a vhodnou knihovnu napsanou v C na pár nízkoúrovňových záležitostí. V C stejně mnoho vlastností, které mají jiné dnešní jazyky, emulujete pomocí maker. Jsou tam, jen jejich realizace je tak trochu křečovitá.

Kdysi byly i pokusy postavit HW šitý na míru Java VM. Viz třeba picojava. Takže byste nízkoúrovňové věci mohl psát rovnou v Javě.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Martin 30. 03. 2016, 10:00:14
Já osobně neznám pythonský projekt podobného rozsahu a nasazení. Jestli ho někdo zná, rád se nechám poučit.

OpenStack?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: pavlix 30. 03. 2016, 10:44:59
Já osobně neznám pythonský projekt podobného rozsahu a nasazení. Jestli ho někdo zná, rád se nechám poučit.

OpenStack?

Bull's eye!
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 30. 03. 2016, 12:43:33
Drtivá většina jazyků, které znám, a které jsem používal a používám tak REPL, nebo implementačně nezávislou velikost čísla mají. A jsou zcela jiné oproti Pythonu.

Python není jediný, to jsem snad netvrdil. Tvrdil jsem, že Python má tyhle "vymoženosti", že má i jiné příjemné vlastnosti, které nemá třeba Java a jiné mainstreamové jazyky. Tvoji argumentaci nechápu.
Nemůžeš porovnávat Python s nejblbějším jazykem na trhu. To zase nechápu já.

V kontextu vlákna se ptám na to, v čem vidíš výhody Pythonu.

Jestli to u tebe skončí jako v jiných případech, že prostě Python má spešl filozofii, kterou musíš pochopit, a ohromě ti pomůže při vyvoji, ale nepovím ti jakou ani jak - tak mě naštveš.

Psal jsem, že u psaní Pythonu mám pocit, že musím méně přizpůsobovat myšlení jazyku a mohu se soustředit na problém, než u jiných jazyků, které jsem zkoušel.
OK

Jenže se s ním dobře dělá (osobní zkušenost, jak to mám asi popsat), má spoustu knihoven, fajn komunitu se spoustou zkušeností atd.
Tohle je třeba právě to, co mě zajímá. Že je to těžké, shrnout heslovitě v čem je Python výjimečný, může být.

Třeba za mě, má Python jednu jedinou výjimečnou vlastnost: syntax sugar. Ve všem ostatním je to otravný jazyk. Počínaje nepohodlnými bindingi na C, duck-typingem konče.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 30. 03. 2016, 13:06:28
Jsou lidé, kteří si o to prostě říkají.
V pohodě, jestli jsem řekl něco blbě, tak si zasloužím za uši, nemám s tím problém.

Velký projekt je třeba i linuxové jádro a nikdo ho nechce psát v Pythonu.
Nerozumím tomu, kam tímhle argumentem míříš. Moje pozice je "psaní středních a velkých projektů v pythonu přináší rizika, která by člověk měl znát, než se do něčeho takového pustí". Jak s tím souvisí tvrzení "existují velké projekty, které nikdo do Pythonu přepisovat nechce"?

Rozumná diskuse má dojít k poznání, kde jsou konkrétnější hranice použitelnosti či vhodnosti.
Ony ale žádné takové hranice nejsou. Čím větší projekt, tím musí být schopnější tým, aby to ustál. A opakuju: není mi jasné, proč by to dělal, co by tím získal. U většího projektu se podle mě výhody stírají a nevýhody zůstávají.

Generální - blbý výrok, že Python není vhodný na větší projekty (pokud nebyl vyřčen obecně, tak mě klidně oprav)
Mnou doufám nebyl. Pokud ano, chtěl bych vidět citaci.

K Julii - ta se vůbec netají tím, že se tlačí na pozici Pythonu v dané doméně. Mně se docela líbí, proč ne. Dosud není ani ve verzi 1, když se začal prosazovat Python v této oblasti, tak snad ani neexistovala.
To je irelevantní. Python taky neexistoval, když v téhle oblasti fungoval Fortran...

Skoro začínám mít dojem, že se snažíš Python shazovat za každou cenu - napřed přizvukuješ trollujícím javistům a pak se divíš, proč někdo chce "mermomocí" v tomto století dát pro určitý typ vědeckých výpočtů přednost Pythonu před C nebo Fortranem...
Ne, já se tomu vůbec nedivím. Oblast (obecně) zpracování dat enormně roste a přichází do ní spousta nových lidí, kteří to dřív nedělali (já jsem jeden z nich). No a jaký jazyk s nevětší pravděpodobností umí? Python. Tak ho tam dáme, aby se nemuseli učit to divné Rko. I když se python na tu doménu hodí míň než Rko.

Pokud máš pocit, že píšu něco špatně, klidně mě oprav. Bohužel ale nemám u Tebe také zrovna pocit, že bys vždycky diskutoval férově a snažil se dojít k pravdivému výsledku padni komu padni. Viz výše.
Však to jsem udělal :) Snažil jsem se korigovat tvoje tvrzení, který mi přišly zavádějící.

Jestli on nebude zakopaný pes tady:
Tady se zřejmě nechápeme. Poučenou kritiku Pythonu rozhodně vítám a netvrdím, že Ty, M. Prýmek a spol. neznáte nic než Python. Snažil jsem se vypořádat s potenciální radou opustit Python a hledat jinde
Z mé strany ta rada byla "nenechat se zmást prvním dojmem, jak projekt poroste, objeví se úplně jiné problémy než na začátku". A myslím, že ani moc nejsme ve sporu, jenom se možná trochu lišíme v hodnocení závažnosti a dopadů tohodle:

To samozřejmě platí o všech jazycích, ale ty dynamické k nekázni svádějí možná o něco více.
- já mám prostě obavu, že běžní programátoři do té nekázněspadnou (míň nebo víc, v té nebo oné formě) prakticky s jistotou.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 30. 03. 2016, 13:07:48
OpenStack?
Ok, to je dobrý příklad, beru.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 30. 03. 2016, 13:15:16
V kontextu vlákna se ptám na to, v čem vidíš výhody Pythonu.
To je přesně i moje otázka. Rozumím tomu, že po jistou dobu Python moc neměl konkurenci, ale dneska když si vezmu libovolný moderní jazyk s typovou inferencí a dobrou syntaxí, tak mě moc výhod Pythonu nenapadá, jenom samé nevýhody. Kromě snad velkého množství knihoven. Ale to třeba já řeším tak, že s Pythonem komunikuju přes socket z Elixiru (pokud fakt chci nějakou pythonní knihovnu použít a není alternativa v Elixiru - naposledy jsem takhle použil třeba knihovnu pro Request Tracker on cz.nic).
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondra Satai Nekola 30. 03. 2016, 13:27:29
V kontextu vlákna se ptám na to, v čem vidíš výhody Pythonu.
To je přesně i moje otázka. Rozumím tomu, že po jistou dobu Python moc neměl konkurenci, ale dneska když si vezmu libovolný moderní jazyk s typovou inferencí a dobrou syntaxí, tak mě moc výhod Pythonu nenapadá, jenom samé nevýhody. Kromě snad velkého množství knihoven. Ale to třeba já řeším tak, že s Pythonem komunikuju přes socket z Elixiru (pokud fakt chci nějakou pythonní knihovnu použít a není alternativa v Elixiru - naposledy jsem takhle použil třeba knihovnu pro Request Tracker on cz.nic).

Napada mne ke knihovnam jeste dve vyhody - tooling a lidi.

Z dnesniho pohledu uz je to horsi jazyk, ale porad to muze byt lepsi volba.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 30. 03. 2016, 13:37:22
Napada mne ke knihovnam jeste dve vyhody - tooling a lidi.
A tooling pro python je co a čím to překonává tooling pro jiné jazyky?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ondra Satai Nekola 30. 03. 2016, 13:46:17
Napada mne ke knihovnam jeste dve vyhody - tooling a lidi.
A tooling pro python je co a čím to překonává tooling pro jiné jazyky?

Jupyter pro dalsi jazyky porad nic moc, pro Python maji IDE JetBrains... Porad to neni Java, ale na druhou stranu, vetsina dalsich jazyku je na tom o dost hur.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 30. 03. 2016, 14:00:38
Jupyter pro dalsi jazyky porad nic moc, pro Python maji IDE JetBrains... Porad to neni Java, ale na druhou stranu, vetsina dalsich jazyku je na tom o dost hur.
Jupyter je fajn, to je jasný, ale jednak to moc nesouvisí s tématem (je to spíš na interaktivní hraní si a nějakou tu práci s daty) a navíc já radši používám RStudio, přijde mi daleko pokročilejší. Jupyter je fajn na dema a interaktivní práci, kterou chceš mít zdokumentovanou. Ale jakmile si třeba napíšeš nějaké funkce a chceš jim měnit parametry a sledovat výstup, začíná to být opruz a nic moc to pak už nepřináší. V tomhle stadiu už mám radši RStudio + Knitr (pokud chci ty reporty).
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 30. 03. 2016, 15:39:58
Kromě snad velkého množství knihoven.
To máš tak. Máš problém (v mém případě parsování pdf). Hledáš nějakou šikovnou knihovnu, která to umí - najdeš, ale je implementovaná v Pythonu. Nu což, nedá se nic dělat. Tak ji začneš používat, a pak zjistíš, že má bug - normální věc. Tak se v tom začneš vrtat, že to fixneš, nebo tak něco... no a hned máš problémy dva.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: gl 30. 03. 2016, 17:13:25

To máš tak. Máš problém (v mém případě parsování pdf). Hledáš nějakou šikovnou knihovnu, která to umí - najdeš, ale je implementovaná v Pythonu. Nu což, nedá se nic dělat. Tak ji začneš používat, a pak zjistíš, že má bug - normální věc. Tak se v tom začneš vrtat, že to fixneš, nebo tak něco... no a hned máš problémy dva.
[/quote]

Nerozumím. Jak to souvisí s tím, že je ta knihovna implementovaná v pythonu.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 30. 03. 2016, 17:43:14

To máš tak. Máš problém (v mém případě parsování pdf). Hledáš nějakou šikovnou knihovnu, která to umí - najdeš, ale je implementovaná v Pythonu. Nu což, nedá se nic dělat. Tak ji začneš používat, a pak zjistíš, že má bug - normální věc. Tak se v tom začneš vrtat, že to fixneš, nebo tak něco... no a hned máš problémy dva.

Nerozumím. Jak to souvisí s tím, že je ta knihovna implementovaná v pythonu.
[/quote]
Protože kód v Pythonu se výborně píše, o dost hůře čte a zoufale špatně udržuje. Toť má zkušenost.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 30. 03. 2016, 19:54:25
Protože kód v Pythonu se výborně píše, o dost hůře čte a zoufale špatně udržuje. Toť má zkušenost.

S tím tedy nemůžu souhlasit.

Co tě k tomu názoru vede? Já tohle slyšel několikrát u perlu (kde je spousta cest, jak udělat jednu a tu samou věc a nadužívání regexpů je bráno jako standard), ale o pythonu tedy opravdu poprvé.

Ze všech jazyků, kde jsem kdy dělal mi přijde čitelnost python kódu určitě nejlepší, tak by mě vážně zajímalo, jak jsi k tomu dospěl.

To s tou údržbou by si taky zasloužilo nějaké bližší vysvětlení. Asi by se dalo vinit shizma kolem 2 / 3 verze, ale to je tak všechno, co mě napadá.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 31. 03. 2016, 01:14:20
Protože kód v Pythonu se výborně píše, o dost hůře čte a zoufale špatně udržuje. Toť má zkušenost.

S tím tedy nemůžu souhlasit.
:-) To můžeš.

Co tě k tomu názoru vede?
Moje zkušenosti s jeho používáním.

Ze všech jazyků, kde jsem kdy dělal mi přijde čitelnost python kódu určitě nejlepší, tak by mě vážně zajímalo, jak jsi k tomu dospěl.
Myslím, že bych vyjmenoval pár jazyků, které bych dal před něj. Začal bych Haskellem.

To s tou údržbou by si taky zasloužilo nějaké bližší vysvětlení.
Jakmile tam někde něco chci změnit, začne to vystřeloval chyby a rozpadá se to. Prostě já s ním nedělám rád.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 31. 03. 2016, 08:15:34
Myslím, že bych vyjmenoval pár jazyků, které bych dal před něj. Začal bych Haskellem.

To je velmi odvážné tvrzení. Haskellovská syntaxe je úsporná, ale obliba infixových funkcí trochu připomíná jazyky typu J a transformátory monád apod. spolehlivě vylámou zuby 99% běžných programátorů.

Na druhou stranu, jak říká jeden známý, v Perlu lze psát v každém jazyce, takže klidně věřím, že ses setkal s Pythonem, který byl hůře čitelný než Haskell. Nebo ses narodil s IO monádou na čele, klidně věřím, že pro někoho je Haskell z nějakého důvodu pro někoho přirozenější.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 08:26:30
To s tou údržbou by si taky zasloužilo nějaké bližší vysvětlení.
Jakmile tam někde něco chci změnit, začne to vystřeloval chyby a rozpadá se to. Prostě já s ním nedělám rád.
Není rozdíl v tom, když vám chyby vyhodí překladač a když chyby vyhodí runtime. Chyba je chyba a je jedno v kterém kroku se na ni přijde. Jedno to nebylo před 30 lety, kdy byl strojový čas drahý.

V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné, už jenom proto, že musíte pracovat se všemi pravidly najednou a nebo neustále ověřovat, jaké pravidlo bylo uplatněno v daném místě. Velkou paseku nadělají i "e-pravidla", pak musíte hledat všechna pravidla, která se mohou v daném místě vyskytnout místo "e-pravidla" a to stále znovu a znovu.

Jazyk aplikace se pak "syntetizuje", tedy na každou akci si musíte vytvořit vlastní slovo (funkci), které získáváte odvozováním od už existujíích slov (funkcí), takže závislosti vznikají mnohem horší než u imperativních jazyků, kde můžete rozumně závislosti omezit na okolí funkce, či metody.

Výhody FP jsou zdánlivé, protože toto paradigma není široce používáno a každý kdo ho používá se hrabe většinou ve vlastním kódu, takže sdílená údržba různými lidmi není dostatečně ověřena.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Inkvizitor 31. 03. 2016, 08:27:30
V kontextu vlákna se ptám na to, v čem vidíš výhody Pythonu.
To je přesně i moje otázka. Rozumím tomu, že po jistou dobu Python moc neměl konkurenci, ale dneska když si vezmu libovolný moderní jazyk s typovou inferencí a dobrou syntaxí, tak mě moc výhod Pythonu nenapadá, jenom samé nevýhody. Kromě snad velkého množství knihoven. Ale to třeba já řeším tak, že s Pythonem komunikuju přes socket z Elixiru (pokud fakt chci nějakou pythonní knihovnu použít a není alternativa v Elixiru - naposledy jsem takhle použil třeba knihovnu pro Request Tracker on cz.nic).

Pánové, já jsem se to snažil vyjádřit, jak jenom umím. Samozřejmě, že jsem na Python přešel před X lety, kdy mě už nebavilo se trápit s Visual C++ a Java byla strašlivá zpatlanina bez generik a s padajícím IDE Xelfi. Dnes by výběr byl těžší, ale není i tak logické primárně hledat mezi nejpopulárnějšími jazyky, které se nemění za pochodu jako Rust, neobsahují podivná pravidla pro porovnávání identifikátorů jako Nim nebo nerezignují na generika jenom proto, že vývojáři nevědí, jak je naimplementovat, jako Go? Není logické pokukovat po jazyce, který má hned po instalaci k dispozici spoustu knihoven a neinstaluje do systému půl gigabajtu jako jazyky běžící pod Mono? Kromě toho, co jsem už napsal, samozřejmě.

Tvoje volání Pythonu přes sockety mě dost děsí. To to nejde jinak? Julia to třeba umí docela elegantně.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: hawran diskuse 31. 03. 2016, 08:37:55
... Není rozdíl v tom, když vám chyby vyhodí překladač a když chyby vyhodí runtime. Chyba je chyba a je jedno v kterém kroku se na ni přijde...

?

Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 08:44:54
To je velmi odvážné tvrzení. Haskellovská syntaxe je úsporná, ale obliba infixových funkcí trochu připomíná jazyky typu J a transformátory monád apod. spolehlivě vylámou zuby 99% běžných programátorů.
Taky mi to přijde jako docela odvážné (a subjektivní), ale úplná hloupost to není. Připomínky k tomu, co jsi napsal:

Infixy by se měly používat právě tam, kde čitelnost zvyšují (7 `div` 3 místo (div 7 3)  ). A mj. umí zvýšit čitelnost i právě u těch monád. V Elmu:
Kód: [Vybrat]
toInt rawString `andThen` toValidMonth
- andThen je bind operator.

S monádami to je nefér argument ze dvou důvodů:
1. je to konstrukce, kterou Python nemá, takže nemůžeš říct, že má Python lepší syntaxi. Kdyby monády měl, byla by ta syntaxe +/- stejná.
2. Elm dobře ukazuje, jak se dá haskellovská syntaxe zlidštit jenom vhodnou volbou názvů (!) Nemusíš lidi trápit povídáním o skládání funktorů, aby se v tom utopili. Prostě jim řekneš, že se udělá asynchronní akce a a potom akce b. Hotovo dvacet, většině programátorů to bude stačit. Koneckonců promisy v JS jsou taky monády a neřekl bych, že by někdo měl problém napsat .done(...) ;)

klidně věřím, že pro někoho je Haskell z nějakého důvodu pro někoho přirozenější.
Žádný jazyk není "přirozený". Vždycky je to nějaký formalismus, který se musíš naučit.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 08:46:04
V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné
To je samozřejmě opět úplný nesmysl.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: gamer 31. 03. 2016, 08:46:52
Není rozdíl v tom, když vám chyby vyhodí překladač a když chyby vyhodí runtime. Chyba je chyba a je jedno v kterém kroku se na ni přijde. Jedno to nebylo před 30 lety, kdy byl strojový čas drahý.

To vysvětluj zákazníkovi, že je jedno, ve kterém kroku se na chybu přidje, takže když se projeví až u něj, je to v pořádku, protože stojový čas je levný. Nebo adminovi, kterému to o půlnoci v produkci spadne, neví co s tím má dělat a je z toho na prášky, protože každá minuta nedostupnosti stojí dost peněz a když nebude dostupnost 99.9%  nebudou prémie.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 08:52:53
Dnes by výběr byl těžší, ale není i tak logické primárně hledat mezi nejpopulárnějšími jazyky, které se nemění za pochodu jako Rust, neobsahují podivná pravidla pro porovnávání identifikátorů jako Nim nebo nerezignují na generika jenom proto, že vývojáři nevědí, jak je naimplementovat, jako Go? Není logické pokukovat po jazyce, který má hned po instalaci k dispozici spoustu knihoven a neinstaluje do systému půl gigabajtu jako jazyky běžící pod Mono? Kromě toho, co jsem už napsal, samozřejmě.
Pokud bych hledal podle těchto kritérií a chtěl bych relativně mainstreamový jazyk, šel bych nejspíš do Scaly, ta mi přijde jako docela rozumný kompromis. A hned jako první bych samozřejmě pak zvažoval Akka, ale to je moje osobní inklinace, to přiznávám bez mučení ;)

Tvoje volání Pythonu přes sockety mě dost děsí. To to nejde jinak? Julia to třeba umí docela elegantně.
No obecně máš na výběr jenom dvě možnosti:
V Erlangu/Elixiru jde použít oboje, ale to první přináší riziko, že chyba v lepidlu shodí celý Erlang VM, což nechceš. Druhá možnost je pohodlnější a sockety jsou nejrychlejší. Získáš plně dekuplované (to je ale hnusné slovo) komponenty a dobře definované API. Nevidím na tom nic děsivého, naopak - pokud je to výkonově adekvátní, je to nejlepší řešení.

EDIT: no, vlastně se socketama jsem kecal, ona ta komunikace probíhá nejspíš přes normální rouru, ale principielně je to úplně jedno. Prostě http://erlang.org/doc/reference_manual/ports.html
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 09:39:51
V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné
To je samozřejmě opět úplný nesmysl.
To říkejte uživatelům SQL :-)))
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 31. 03. 2016, 10:28:45
V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné
To je samozřejmě opět úplný nesmysl.
To říkejte uživatelům SQL :-)))
Můžu se zeptat, jak předchozí blábol souvísí se SQL? Co jsou v SQL třeba ten generovaný a konkrétní jazyk?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 11:35:11
V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné
To je samozřejmě opět úplný nesmysl.
To říkejte uživatelům SQL :-)))
Můžu se zeptat, jak předchozí blábol souvísí se SQL? Co jsou v SQL třeba ten generovaný a konkrétní jazyk?
Konkrétní jazyk jsou všechny možné žádoucí výsledky SQL dotazu, tedy to, co chcete a můžete z databáze vybrat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.

Generovaný jazyk je dán pravidly v podmínkách WHERE, JOIN atp. v daném příkazu SELECT a pravidly danými kompozicemi příkazů SELECT, konkrétní příkaz SELECT byste mohl převést na gramatiku, která by generovala nějaký jazyk, a platilo by o ní, že každý výsledek tohoto konkrétního dotazu, takto zkonstruovaná gramatika přijme.

No a vaším úkolem v podstatě je, rozhodnout, zda oba jazyky jsou stejné. A to vůbec není triviální záležitost.

A tak nějak to v podstatě i děláte, při konstrukci konkrétního SELECTu si v hlavě vytváříte gramatiku omezujících pravidel (podmínek), která z dat v db vybere požadovaná data. Je-li dotaz složitější, neustále probíráte zapsané podmínky a snažíte se v mysli vygenerovat možný výsledek, abyste se dobral k tomu, jaké pravidlo do příkazu přidat,odebrat či změnit a jak. Realitu modelujete pomocí pravidel, nikoli příkazů, které by měnily a zachovávaly nějaký stav výpočtu, pracujete tedy s gramatikou, aniž byste si to třeba uvědomoval.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 31. 03. 2016, 11:57:16
Konkrétní jazyk jsou všechny možné žádoucí výsledky SQL dotazu, tedy to, co chcete a můžete z databáze vybrat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.

Generovaný jazyk je dán pravidly v podmínkách WHERE, JOIN atp. v daném příkazu SELECT a pravidly danými kompozicemi příkazů SELECT, konkrétní příkaz SELECT byste mohl převést na gramatiku, která by generovala nějaký jazyk, a platilo by o ní, že každý výsledek tohoto konkrétního dotazu, takto zkonstruovaná gramatika přijme.

No a vaším úkolem v podstatě je, rozhodnout, zda oba jazyky jsou stejné. A to vůbec není triviální záležitost.

A tak nějak to v podstatě i děláte, při konstrukci konkrétního SELECTu si v hlavě vytváříte gramatiku omezujících pravidel (podmínek), která z dat v db vybere požadovaná data. Je-li dotaz složitější, neustále probíráte zapsané podmínky a snažíte se v mysli vygenerovat možný výsledek, abyste se dobral k tomu, jaké pravidlo do příkazu přidat,odebrat či změnit a jak. Realitu modelujete pomocí pravidel, nikoli příkazů, které by měnily a zachovávaly nějaký stav výpočtu, pracujete tedy s gramatikou, aniž byste si to třeba uvědomoval.
Tohle ale nijak nesouvisí s deklarativními jazyky. Stačí abych upravil první odstavec na
Citace
Konkrétní jazyk jsou všechny možné žádoucí výsledky programu, tedy to, co chcete a můžete vypočítat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.
Tohle jsou základy teoretické informatiky, které platí pro jakékoliv jazyky, nejen ty deklarativní. Rozhodně se to nedá použít pro jakoukoliv kritiku deklarativních jazyků v porovní s jinými paradigmaty.

Upřímně mám z vašich příspěvků větší a větší pocit, že tu na nás někdo zkouší Turingův test.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 12:08:17
Vůbec není potřeba do toho míchat "generované jazyky". Stačí říct, že každý program (v libovolném jazyce) dává pro nějaký vstup nějaký výstup a tedy každý program je vlastně jenom (nekonečná) tabulka a je děsivácky složité vymyslet program tak, aby ta skutečná tabulka odpovídala té tabulce, kterou chci dostat.

No jistě, pro složité problémy je to složité, ale pro jednoduché problémy je to jednoduché. A implementační jazyk v tom hraje minimální roli.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 12:12:44
Upřímně mám z vašich příspěvků větší a větší pocit, že tu na nás někdo zkouší Turingův test.
Spíš bych řekl, že se Ivan na škole naučil správná klíčová slova, ale správně je aplikovat už ho nenaučili...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 12:28:29
Konkrétní jazyk jsou všechny možné žádoucí výsledky SQL dotazu, tedy to, co chcete a můžete z databáze vybrat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.

Generovaný jazyk je dán pravidly v podmínkách WHERE, JOIN atp. v daném příkazu SELECT a pravidly danými kompozicemi příkazů SELECT, konkrétní příkaz SELECT byste mohl převést na gramatiku, která by generovala nějaký jazyk, a platilo by o ní, že každý výsledek tohoto konkrétního dotazu, takto zkonstruovaná gramatika přijme.

No a vaším úkolem v podstatě je, rozhodnout, zda oba jazyky jsou stejné. A to vůbec není triviální záležitost.

A tak nějak to v podstatě i děláte, při konstrukci konkrétního SELECTu si v hlavě vytváříte gramatiku omezujících pravidel (podmínek), která z dat v db vybere požadovaná data. Je-li dotaz složitější, neustále probíráte zapsané podmínky a snažíte se v mysli vygenerovat možný výsledek, abyste se dobral k tomu, jaké pravidlo do příkazu přidat,odebrat či změnit a jak. Realitu modelujete pomocí pravidel, nikoli příkazů, které by měnily a zachovávaly nějaký stav výpočtu, pracujete tedy s gramatikou, aniž byste si to třeba uvědomoval.
Tohle ale nijak nesouvisí s deklarativními jazyky. Stačí abych upravil první odstavec na
Citace
Konkrétní jazyk jsou všechny možné žádoucí výsledky programu, tedy to, co chcete a můžete vypočítat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou.
Tohle jsou základy teoretické informatiky, které platí pro jakékoliv jazyky, nejen ty deklarativní. Rozhodně se to nedá použít pro jakoukoliv kritiku deklarativních jazyků v porovní s jinými paradigmaty.

Upřímně mám z vašich příspěvků větší a větší pocit, že tu na nás někdo zkouší Turingův test.
Ale dá. Co je podstatou deklarativního programování, nevytváříte postup výpočtu, ale soubor pravidel, kterými se výpočet má řidit, takže musíte být schopen poznat pohledem na ten soubor pravidel, že výsledek po jejich aplikaci, bude odpovídat požadavkům. Přičemž nejste ani schopen predikovat, jak velké změny výsledku vyvolá malá změna pravidel. A pak stojíte před problémem, jak poznat, zda výsledek odpovídá zadání.

U imperativního stylu ten výsledek ověřujete po částech jak konstruujete výpočet. Pouze vylučujete co neodpovídá očekávaní, při přechodu z jednoho stavu do druhého, což můžete snadněji předvídat, dá se určit do kterého kroku je výsledek správně, nemůžete však zaručit, že je to zcela správně za všech okolností. Jisté je, že se časem objeví další chyby.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 12:38:38
Ale dá. Co je podstatou deklarativního programování, nevytváříte postup výpočtu, ale soubor pravidel, kterými se výpočet má řidit, takže musíte být schopen poznat pohledem na ten soubor pravidel, že výsledek po jejich aplikaci, bude odpovídat požadavkům. Přičemž nejste ani schopen predikovat, jak velké změny výsledku vyvolá malá změna pravidel. A pak stojíte před problémem, jak poznat, zda výsledek odpovídá zadání.

U imperativního stylu ten výsledek ověřujete po částech jak konstruujete výpočet. Pouze vylučujete co neodpovídá očekávaní, při přechodu z jednoho stavu do druhého, což můžete snadněji předvídat, dá se určit do kterého kroku je výsledek správně, nemůžete však zaručit, že je to zcela správně za všech okolností. Jisté je, že se časem objeví další chyby.
Učebnicová poučka neodpovídající realitě. O kousek výš jsem použil příklad

Kód: [Vybrat]
toInt rawString `andThen` toValidMonth

což je úplně to samé jako imperativní

Kód: [Vybrat]
toValidMonth(toInt(rawString))

I v natolik "deklarativním" jazyce jako je Prolog, se reálně píše tak, že člověk rozdělí problém na kroky, kterými se má výpočet ubírat. A pokud chce, může si zkontrolovat, že po jednotlivých krocích dostává ten výsledek, který očekává.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 12:39:20
Vůbec není potřeba do toho míchat "generované jazyky". Stačí říct, že každý program (v libovolném jazyce) dává pro nějaký vstup nějaký výstup a tedy každý program je vlastně jenom (nekonečná) tabulka a je děsivácky složité vymyslet program tak, aby ta skutečná tabulka odpovídala té tabulce, kterou chci dostat.

No jistě, pro složité problémy je to složité, ale pro jednoduché problémy je to jednoduché. A implementační jazyk v tom hraje minimální roli.
Ale hraje. Protože skrze jazyk vidíte realitu. Eskymáci mají tisíce výrazů pro sníh, pod každým si představí něco jiného, což my si představit nedovedeme.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 12:47:39
Ale hraje. Protože skrze jazyk vidíte realitu. Eskymáci mají tisíce výrazů pro sníh, pod každým si představí něco jiného, což my si představit nedovedeme.
A jediná země, která nepotřebuje střední vrstvy, je Japonsko, protože jedině Japonců je dost i bez středních vrstev.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 12:47:47
Ale dá. Co je podstatou deklarativního programování, nevytváříte postup výpočtu, ale soubor pravidel, kterými se výpočet má řidit, takže musíte být schopen poznat pohledem na ten soubor pravidel, že výsledek po jejich aplikaci, bude odpovídat požadavkům. Přičemž nejste ani schopen predikovat, jak velké změny výsledku vyvolá malá změna pravidel. A pak stojíte před problémem, jak poznat, zda výsledek odpovídá zadání.

U imperativního stylu ten výsledek ověřujete po částech jak konstruujete výpočet. Pouze vylučujete co neodpovídá očekávaní, při přechodu z jednoho stavu do druhého, což můžete snadněji předvídat, dá se určit do kterého kroku je výsledek správně, nemůžete však zaručit, že je to zcela správně za všech okolností. Jisté je, že se časem objeví další chyby.
Učebnicová poučka neodpovídající realitě. O kousek výš jsem použil příklad

Kód: [Vybrat]
toInt rawString `andThen` toValidMonth

což je úplně to samé jako imperativní

Kód: [Vybrat]
toValidMonth(toInt(rawString))

I v natolik "deklarativním" jazyce jako je Prolog, se reálně píše tak, že člověk rozdělí problém na kroky, kterými se má výpočet ubírat. A pokud chce, může si zkontrolovat, že po jednotlivých krocích dostává ten výsledek, který očekává.
Ano, a pak přidá jedno pravidlo a výsledek bude prázdná tabulka. Najít proč, znamená zkoušet různé kombinace všech pravidel a hledat s kterým se nově přidané pravidlo vylučuje. Co prolog, stačí CSS a mnohdy je docela oříšek nalézt pravidlo, které  vám brání v posunutí obrázku na správné místo. Jen pohledem na vyrenderovaný výsledek a porovnámím se zdrojovými soubory nemáte šanci na to vůbec přijít. Musíte si vypsat, jaká pravidla a v jakém pořadí je renderovací jádro použilo.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 31. 03. 2016, 12:48:46
Ale hraje. Protože skrze jazyk vidíte realitu. Eskymáci mají tisíce výrazů pro sníh, pod každým si představí něco jiného, což my si představit nedovedeme.
Přirozené a programovací jazyky jsou dost odlišné kategorie. Míchat je dohromady je hodně nebezpečné.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 12:51:48
Ano, a pak přidá jedno pravidlo a výsledek bude prázdná tabulka.
...úplně stejně jako u imperativního jazyka:

Kód: [Vybrat]
for(int x; x<10;x++) {
  printf("%d\n",x);
}

Hledej, babo, kde jsem přidal blbě pravidlo :)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: hawran diskuse 31. 03. 2016, 12:54:11
... Konkrétní jazyk jsou všechny možné žádoucí výsledky SQL dotazu, tedy to, co chcete a můžete z databáze vybrat, většinou to ani přesně neznáte, ale můžete to popsat nějakou gramatikou. ...
:o
;D

I tenhle se mi moc líbil:
... Dynamický jazyk je světe div se dynamický, a ta dynamičnost byla jednou z motivací, co stála u jeho zrodu a je to jeho výhoda, která odpovídá zvolenému přístupu. Opačně to platí o statických jazycích. ...
;D  ;D  ;D
Název: Re:Python - dobré rady a praktiky
Přispěvatel: zboj 31. 03. 2016, 13:04:52
Ale hraje. Protože skrze jazyk vidíte realitu. Eskymáci mají tisíce výrazů pro sníh, pod každým si představí něco jiného, což my si představit nedovedeme.
Přirozené a programovací jazyky jsou dost odlišné kategorie. Míchat je dohromady je hodně nebezpečné.

Montague si to nemyslel.
"There is in my opinion no important theoretical difference between natural languages and the artificial languages of logicians; indeed I consider it possible to comprehend the syntax and semantics of both kinds of languages with a single natural and mathematically precise theory."
Název: Re:Python - dobré rady a praktiky
Přispěvatel: zboj 31. 03. 2016, 13:09:18
Vůbec není potřeba do toho míchat "generované jazyky". Stačí říct, že každý program (v libovolném jazyce) dává pro nějaký vstup nějaký výstup a tedy každý program je vlastně jenom (nekonečná) tabulka a je děsivácky složité vymyslet program tak, aby ta skutečná tabulka odpovídala té tabulce, kterou chci dostat.

No jistě, pro složité problémy je to složité, ale pro jednoduché problémy je to jednoduché. A implementační jazyk v tom hraje minimální roli.
Ale hraje. Protože skrze jazyk vidíte realitu. Eskymáci mají tisíce výrazů pro sníh, pod každým si představí něco jiného, což my si představit nedovedeme.
http://www.lel.ed.ac.uk/~gpullum/EskimoHoax.pdf
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 13:17:06
Ano, a pak přidá jedno pravidlo a výsledek bude prázdná tabulka.
...úplně stejně jako u imperativního jazyka:

Kód: [Vybrat]
for(int x; x<10;x++) {
  printf("%d\n",x);
}

Hledej, babo, kde jsem přidal blbě pravidlo :)
To ale není dobrý příklad, protože existuje jednoznačný postup, jak se k té chybě dostat, aniž byste musel nějak složitě zkoumat logiku algoritmu, jen sledujete co se kde děje.

Když podobně zareaguje 200 řádkový SELECT, tak to tak jednoznačné nebývá :-)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 31. 03. 2016, 13:19:46
Montague si to nemyslel.
"There is in my opinion no important theoretical difference between natural languages and the artificial languages of logicians; indeed I consider it possible to comprehend the syntax and semantics of both kinds of languages with a single natural and mathematically precise theory."
Teoretické rozdíly mezi nimi možná nejsou, ale ty praktické myslím bohatě stačí. Rozdíly v úspěšnosti překladačů přirozených a programovacích jazyků to IMO ilustrují dostatečně. Nemám problém s tím, hledat mezi nimi podobnosti a společnou teorii. Mám problém s tím, když se bezstarostně strkají do jednoho pytle.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 13:22:11
Vůbec není potřeba do toho míchat "generované jazyky". Stačí říct, že každý program (v libovolném jazyce) dává pro nějaký vstup nějaký výstup a tedy každý program je vlastně jenom (nekonečná) tabulka a je děsivácky složité vymyslet program tak, aby ta skutečná tabulka odpovídala té tabulce, kterou chci dostat.

No jistě, pro složité problémy je to složité, ale pro jednoduché problémy je to jednoduché. A implementační jazyk v tom hraje minimální roli.
Ale hraje. Protože skrze jazyk vidíte realitu. Eskymáci mají tisíce výrazů pro sníh, pod každým si představí něco jiného, což my si představit nedovedeme.
http://www.lel.ed.ac.uk/~gpullum/EskimoHoax.pdf
Dobře, jiný příklad. Rozdíl ve vnímání vyplývající z rozdílů mezi analytickým(imperitativním) a syntetickým(deklarativním) jazykem. Barvy a rozdíly v jejich vnímání mezi muži a ženami. Muži ve svém projevu tolik barev jako ženy nepoužívají a ani je nerozeznávají, obě skupiny tedy hovoří jinými jazyky, i když si myslí, že hovoří stejným jazykem.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: hawran diskuse 31. 03. 2016, 13:24:41
http://www.lel.ed.ac.uk/~gpullum/EskimoHoax.pdf

No pěkně!
 :)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: hawran diskuse 31. 03. 2016, 13:30:26
... Barvy a rozdíly v jejich vnímání mezi muži a ženami. Muži ve svém projevu tolik barev jako ženy nepoužívají a ani je nerozeznávají, obě skupiny tedy hovoří jinými jazyky, i když si myslí, že hovoří stejným jazykem.
;)
(http://www.jenprozeny.cz/sites/default/files/imagecache/dust_nodegrid_big/gallery/24545/55496.jpg)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 31. 03. 2016, 13:35:25
Dobře, jiný příklad. Rozdíl ve vnímání vyplývající z rozdílů mezi analytickým(imperitativním) a syntetickým(deklarativním) jazykem. Barvy a rozdíly v jejich vnímání mezi muži a ženami. Muži ve svém projevu tolik barev jako ženy nepoužívají a ani je nerozeznávají, obě skupiny tedy hovoří jinými jazyky, i když si myslí, že hovoří stejným jazykem.
Pořád mluvíte o přirozených a ne o programovacích jazycích. Na analytické a syntetické se dělí právě ty přirozené.
A když už dáváte dokupy syntetické a deklarativní jazyky, tak čeština je spíš syntetický než analytický jazyk. Takže ty deklarativní by měly být našemu myšlení bližší, ne? :D
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 13:51:28
Dobře, jiný příklad. Rozdíl ve vnímání vyplývající z rozdílů mezi analytickým(imperitativním) a syntetickým(deklarativním) jazykem. Barvy a rozdíly v jejich vnímání mezi muži a ženami. Muži ve svém projevu tolik barev jako ženy nepoužívají a ani je nerozeznávají, obě skupiny tedy hovoří jinými jazyky, i když si myslí, že hovoří stejným jazykem.
Pořád mluvíte o přirozených a ne o programovacích jazycích. Na analytické a syntetické se dělí právě ty přirozené.
A když už dáváte dokupy syntetické a deklarativní jazyky, tak čeština je spíš syntetický než analytický jazyk. Takže ty deklarativní by měly být našemu myšlení bližší, ne? :D
Ano, toto mě před chvilkou napadlo taky. No ono není náhoda, že umělé programovací jazyky vznikly v anglosaském prostředí, už od žakárových pletacích strojů. Nápad, že akce stroje může souviset s pořadím, jako slova ve větě. To by Čecha nenapadlo. Ve světě syntetických jazyků by se možná dala vysledovat souvislost s chemií, ta staví na jiném vidění světa.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 31. 03. 2016, 14:02:44
Ano, toto mě před chvilkou napadlo taky. No ono není náhoda, že umělé programovací jazyky vznikly v anglosaském prostředí, už od žakárových pletacích strojů. Nápad, že akce stroje může souviset s pořadím, jako slova ve větě. To by Čecha nenapadlo. Ve světě syntetických jazyků by se možná dala vysledovat souvislost s chemií, ta staví na jiném vidění světa.
A nebo to náhoda je. Těch vlivů je spousta. A spousta významných jmen kolem počátků informatiky rozhodně z anglosaského prostředí nepochází.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 14:15:13
A nebo to náhoda je. Těch vlivů je spousta. A spousta významných jmen kolem počátků informatiky rozhodně z anglosaského prostředí nepochází.
Jedním z prvních, kdo se modelováním kroků výpočtu zabýval, byl Gödel, který se narodil v Brně, ale mluvil Německy. Tak nevím, co z toho asi plyne pro vlastnosti deklarativních jazyků :)))
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 14:22:28
A nebo to náhoda je. Těch vlivů je spousta. A spousta významných jmen kolem počátků informatiky rozhodně z anglosaského prostředí nepochází.
Jedním z prvních, kdo se modelováním kroků výpočtu zabýval, byl Gödel, který se narodil v Brně, ale mluvil Německy. Tak nevím, co z toho asi plyne pro vlastnosti deklarativních jazyků :)))
Ada Lovelace byla o 80 let starší než Kurt Godel, ale jeho otec vlastnil textilní továrnu (podle Wikipedie), kupodivu, třeba si Godel jako dítě hrál s děrnými štítky od firmy Hollerith  :-)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Mirek Prýmek 31. 03. 2016, 14:25:28
Ada Lovelace byla o 80 let starší než Kurt Godel, ale jeho otec vlastnil textilní továrnu (podle Wikipedie), kupodivu, třeba si Godel jako dítě hrál s děrnými štítky od firmy Hollerith  :-)
To je pravda, na Adu jsem úplně zapomněl. Tak teď už je to jasný, proč jsou deklarativní jazyky tak blbý.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 31. 03. 2016, 14:30:30
Ada Lovelace byla o 80 let starší než Kurt Godel, ale jeho otec vlastnil textilní továrnu (podle Wikipedie), kupodivu, třeba si Godel jako dítě hrál s děrnými štítky od firmy Hollerith  :-)
To je pravda, na Adu jsem úplně zapomněl. Tak teď už je to jasný, proč jsou deklarativní jazyky tak blbý.
Já bych šel podstatně dál. Třeba k takovým flašinetům.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 14:36:18
Ada Lovelace byla o 80 let starší než Kurt Godel, ale jeho otec vlastnil textilní továrnu (podle Wikipedie), kupodivu, třeba si Godel jako dítě hrál s děrnými štítky od firmy Hollerith  :-)
To je pravda, na Adu jsem úplně zapomněl. Tak teď už je to jasný, proč jsou deklarativní jazyky tak blbý.
Tak zpracování dat na děrnoštítkovém stroji je ve stylu FP. Děrnoštítkové stroje uměly snad jen sort, map, reduce a sum a data na štítku byla imutabilní :-) U nás byly první děrnoštítkové stroje v roce 1929.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Kiwi 31. 03. 2016, 14:50:09
Další diskuse na téma „co je lepší na reálné nasazení – vrtulník nebo letadlo?”
Název: Re:Python - dobré rady a praktiky
Přispěvatel: zboj 31. 03. 2016, 14:56:58
Montague si to nemyslel.
"There is in my opinion no important theoretical difference between natural languages and the artificial languages of logicians; indeed I consider it possible to comprehend the syntax and semantics of both kinds of languages with a single natural and mathematically precise theory."
Teoretické rozdíly mezi nimi možná nejsou, ale ty praktické myslím bohatě stačí. Rozdíly v úspěšnosti překladačů přirozených a programovacích jazyků to IMO ilustrují dostatečně. Nemám problém s tím, hledat mezi nimi podobnosti a společnou teorii. Mám problém s tím, když se bezstarostně strkají do jednoho pytle.
Jasně, ale to je jen tím, že gramatika formálních jazyků je (v podstatě) jednoznačná.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: zboj 31. 03. 2016, 14:58:13
http://www.lel.ed.ac.uk/~gpullum/EskimoHoax.pdf

No pěkně!
 :)
Nedalo mi to, no...
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 31. 03. 2016, 15:06:08
Myslím, že bych vyjmenoval pár jazyků, které bych dal před něj. Začal bych Haskellem.

To je velmi odvážné tvrzení. Haskellovská syntaxe je úsporná, ale obliba infixových funkcí trochu připomíná jazyky typu J a transformátory monád apod. spolehlivě vylámou zuby 99% běžných programátorů.

Na druhou stranu, jak říká jeden známý, v Perlu lze psát v každém jazyce, takže klidně věřím, že ses setkal s Pythonem, který byl hůře čitelný než Haskell. Nebo ses narodil s IO monádou na čele, klidně věřím, že pro někoho je Haskell z nějakého důvodu pro někoho přirozenější.
Můžeš si všimnout, že jsem nikde nic o monádách nepsal. Taky jsem nikde nepsal o tom, že Haskell je lepší jak Python. Reagoval jsem, že co se čitelnosti, je na tom Haskell lépe. IMHO.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: BoneFlute 31. 03. 2016, 15:10:30
To s tou údržbou by si taky zasloužilo nějaké bližší vysvětlení.
Jakmile tam někde něco chci změnit, začne to vystřeloval chyby a rozpadá se to. Prostě já s ním nedělám rád.
Není rozdíl v tom, když vám chyby vyhodí překladač a když chyby vyhodí runtime. Chyba je chyba a je jedno v kterém kroku se na ni přijde. Jedno to nebylo před 30 lety, kdy byl strojový čas drahý.
Rozhodně není.

V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné, už jenom proto, že musíte pracovat se všemi pravidly najednou a nebo neustále ověřovat, jaké pravidlo bylo uplatněno v daném místě. Velkou paseku nadělají i "e-pravidla", pak musíte hledat všechna pravidla, která se mohou v daném místě vyskytnout místo "e-pravidla" a to stále znovu a znovu.

Jazyk aplikace se pak "syntetizuje", tedy na každou akci si musíte vytvořit vlastní slovo (funkci), které získáváte odvozováním od už existujíích slov (funkcí), takže závislosti vznikají mnohem horší než u imperativních jazyků, kde můžete rozumně závislosti omezit na okolí funkce, či metody.
Abych šetřil svou klávesnici - prostě to otoč, a budeš znát můj názor.

Výhody FP jsou zdánlivé, protože toto paradigma není široce používáno a každý kdo ho používá se hrabe většinou ve vlastním kódu, takže sdílená údržba různými lidmi není dostatečně ověřena.
To nemohu potvrdit. Ve většině haskellovského kódu, co jsem si přitáhl z cabalu jsem se celkem dobře orientoval, a když jsem něco potřeboval, tak to doslova spolupracovalo. Navzdory tomu, že i Haskellisti trpí nemocí, "na co dokumentace".
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Ivan Nový 31. 03. 2016, 15:29:39
To s tou údržbou by si taky zasloužilo nějaké bližší vysvětlení.
Jakmile tam někde něco chci změnit, začne to vystřeloval chyby a rozpadá se to. Prostě já s ním nedělám rád.
Není rozdíl v tom, když vám chyby vyhodí překladač a když chyby vyhodí runtime. Chyba je chyba a je jedno v kterém kroku se na ni přijde. Jedno to nebylo před 30 lety, kdy byl strojový čas drahý.
Rozhodně není.

V každém "deklarativním" jazyku je chybu težší odhalit, protože odvozovací pravidla generují vlastní jazyk a vyřešit úlohu, zda generovaný jazyk, odpovídá konkrétnímu jazyku a zamýšlenému účelu, je dosti náročné, už jenom proto, že musíte pracovat se všemi pravidly najednou a nebo neustále ověřovat, jaké pravidlo bylo uplatněno v daném místě. Velkou paseku nadělají i "e-pravidla", pak musíte hledat všechna pravidla, která se mohou v daném místě vyskytnout místo "e-pravidla" a to stále znovu a znovu.

Jazyk aplikace se pak "syntetizuje", tedy na každou akci si musíte vytvořit vlastní slovo (funkci), které získáváte odvozováním od už existujíích slov (funkcí), takže závislosti vznikají mnohem horší než u imperativních jazyků, kde můžete rozumně závislosti omezit na okolí funkce, či metody.
Abych šetřil svou klávesnici - prostě to otoč, a budeš znát můj názor.

Výhody FP jsou zdánlivé, protože toto paradigma není široce používáno a každý kdo ho používá se hrabe většinou ve vlastním kódu, takže sdílená údržba různými lidmi není dostatečně ověřena.
To nemohu potvrdit. Ve většině haskellovského kódu, co jsem si přitáhl z cabalu jsem se celkem dobře orientoval, a když jsem něco potřeboval, tak to doslova spolupracovalo. Navzdory tomu, že i Haskellisti trpí nemocí, "na co dokumentace".
Nyní v Haskellu dělají lidi co ho mají rádi, idealisti, jazyk a přístupy v něm prověří až lidé, které ta práce nebaví a dělají to třeba jen pro peníze.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: JSH 31. 03. 2016, 15:47:27
Jasně, ale to je jen tím, že gramatika formálních jazyků je (v podstatě) jednoznačná.
A gramatika těch přirozených (jsou vůbec nějaké výjimky?) nejednoznačná. Není to dostatečný praktický rozdíl?
Název: Re:Python - dobré rady a praktiky
Přispěvatel: F 31. 03. 2016, 16:13:45
To tu docela začíná připomínat http://existentialcomics.com/comic/68
Název: Re:Python - dobré rady a praktiky
Přispěvatel: hawran diskuse 31. 03. 2016, 17:19:15
Ahoj,
...
Mam tedy otazku na zkusenejsi programatory v Pythonu. Mohli by jste mi doporucit knizku nebo internetovy zdroj o dobrych praktikach a pristupech, jak v Pythonu rozume programovat? Tech zdroju na internetu je hrozne moc, a nevim, ktery je kvalitni.
...
Chtel bych neco na tema OOP (spoustu let programuju v Jave, ktera ma OOP pojate docela jinak nez v py) nebo obecne praktiky...

Diky za rady! :)

Tak snad Ti to pomohlo.
Nemáš zač.
 ;)
Název: Re:Python - dobré rady a praktiky
Přispěvatel: gl 31. 03. 2016, 18:27:23
Ahoj,
...
Mam tedy otazku na zkusenejsi programatory v Pythonu. Mohli by jste mi doporucit knizku nebo internetovy zdroj o dobrych praktikach a pristupech, jak v Pythonu rozume programovat? Tech zdroju na internetu je hrozne moc, a nevim, ktery je kvalitni.
...
Chtel bych neco na tema OOP (spoustu let programuju v Jave, ktera ma OOP pojate docela jinak nez v py) nebo obecne praktiky...

Diky za rady! :)

Tak snad Ti to pomohlo.
Nemáš zač.
 ;)

Mnoho knih jsem nepřečetl. Doporučil bych Python Cookbook a Test-Driven Development with Python. Ještě jsem přečetl Two Scoops of Django, což je kniha která obsahuje hlavně obecné povídání a subjektiví názory na best practices. Přínosnější je si prohlédnout nějaký reálný projekt. V češtině vyšla kniha Python 3 výukový kurz. Knihu mám koupenou. Moc se mi nelíbí překlad.

Určitě bych doporučil nějaký plugin do editoru pro kontrolu dodržování konvencí a prevenci překlepů. OOP se zabývá téměř každá kniha.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: Bystroushaak 01. 04. 2016, 10:17:46
Intermediate python (https://leanpub.com/intermediatepython) docela ušla. The Little Book of Python Anti-Patterns (http://docs.quantifiedcode.com/python-anti-patterns/index.html) taky není špatná.
Název: Re:Python - dobré rady a praktiky
Přispěvatel: suic 01. 04. 2016, 14:18:43
Treba Fluent Python (http://shop.oreilly.com/product/0636920032519.do)