<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Dne 11. února 2015 10:08 Vladimir Macek <span dir="ltr"><<a href="mailto:macek@sandbox.cz" target="_blank">macek@sandbox.cz</a>></span> napsal(a):<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10.2.2015 20:50, Honza Král wrote:<br>
> 2015-02-10 20:36 GMT+01:00 Radek Holý <<a href="mailto:radekholypublic@gmail.com">radekholypublic@gmail.com</a>>:<br>
</span><span class="">>> V Pythonu dělám skoro 9 let a pořád platí, že kdykoliv někde<br>
>> narazím na "reduce", "map" apod. tak mě to vždy zdrží a chvíli mi<br>
>> trvá, než pochopím o co jde. List comprehensions se mi čtou<br>
>> snadněji - přirozeněji. Nehledě na to, že ty funkcionální<br>
>> záležitosti jsou skoro vždy spojené s deklarací jinak zbytečných<br>
>> funkcí se složitým významem, nebo ještě komplikovanějšími lambda<br>
>> funkcemi. Každopádně je to prostě otázku vkusu/zvyku... Jedním z<br>
>> problémů může pro mě být ta prefixová notace. Vypadá to jako Lisp<br>
>> :-)<br>
<br>
</span>Doufám, že se shodneme, že to je věc osobních preferencí a nebudeme si to<br>
navzájem vyčítat. :-) Zajisté můžu považovat za elegantnější vytáhnout<br>
filtrační nebo transformační logiku do extra funkce s komentáři a pak jí<br>
předhodit do filter/map než to patlat do třířádkového C-G. Podotýkám pro<br>
jistotu znovu, že používám jak filter/map + zřídka reduce, tak C-G, vždy<br>
podle svého citu pro vhodnost. Snažím se dodržovat Zen.<br>
<br>
Kdykoli píšu \, trošku uvnitř umřu.<br>
<span class=""><br>
<br>
> Vidim to uplne stejne, proto jsem byl prekvapen kdyz tady slysim<br>
> zastance filter/map/... Ja osobne se k nim skutecne uchyluji jen<br>
> obcas kvuli vykonu a v situaci kdy je naprosto jasne, co to bude<br>
> delat.<br>
<br>
</span>To poslední negrokuju. :-) Jasné je snad v Pythonu vše, proto ho máme rádi,<br>
ne? :-)<br>
<span class=""><br>
<br>
>> Ještě mě zarazilo to "stáhneme 10 URL". S tím mám vždy osobní<br>
>> problém. Jakmile někdo volá "map", aniž by ho zajímala návratová<br>
>> hodnota volané funkce, považuji to za chybu. Nehledě na to, že v<br>
>> Pythonu 3 "map" vrací iterátor, takže se kvůli tomu ještě typicky<br>
>> "map" obaluje do "list"... V těchto případech vždy preferuji<br>
>> klasický "for" cyklus. Ale opět je to jen můj názor.<br>
<br>
</span>Dovoluji si i zde spíše nesouhlasit, zejména se slovem typicky.<br>
"Přetypování" tohoto typu snad používáme až tehdy, kdy je to nutné, ne?<br>
Pokud někde dostanu iterátor, je hromada případů, kdy se elegantně a<br>
efektivně použije přímo.<br>
<span class=""><br></span></blockquote><div><br></div><div>U toho přetypování jsem měl na mysli, když se map (nebo list comprehension) použije místo for cyklu, když se už dál nepracuje s návratovými hodnotami. Tehdy se (stále si trvám na) typicky map obaluje do listu, aby se ten výraz vyhodnotil. Jinak samozřejmě nění map potřeba obalovat do listu.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
> Naprosty souhlas, parkrat jsem videl volani map ci list<br>
> comprehension bez zajmu o vysledek a take s tim mam problem - je to<br>
> plytvani (zbytecne se alokuje list) a je to hure citelne.<br>
<br>
</span>Nedochází mi, kde jste vzali, že spojuju příklad se stažením 10 URL s<br>
map(), psal jsem zrovna, že jsem na tom příkladu ilustroval C-G. Ale i na<br>
map() se to dá použít<br></blockquote><div><br></div><div>Moje chyba. Špatně jsem si to zapamatoval. Nicméně moje poznámka se týkala jak list comprehension tak map. V obou případech mi toto použití připadá špatné.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
map(urllib.urlopen, ('<a href="http://www.seznam.cz" target="_blank">http://www.seznam.cz</a>', '<a href="http://google.com" target="_blank">http://google.com</a>',<br>
'<a href="http://ibm.com" target="_blank">http://ibm.com</a>'))<br>
<br>
Též nerozumím tomu, jak jste vyvodili, že se jak v tomto případu, tak v tom<br>
mnou prve zmíněném s C-G nezajímám o návratovou hodnotu.<br></blockquote><div><br></div><div>Nenapadlo mě, k čemu by návratová hodnota mohla být dobrá při stahování souboru. Nevěděl jsem, jako funkci máš na mysli, ale představoval jsem si, že pokud jde o stahování souboru, bude to fce, které zadám url a cestu na disku a ona soubor stáhne, nebo vyhodí výjimku. V takové případě není potřeba žádná návratová hodnota. Pokud nějaká potřeba je, tak je v tom případě vše v pořádku. I když tedy stejně preferuji volání jakýchkoliv funkcí s vedlejším efektem (nebo jaký je správný překlad) ve for cyklu. Když vydím map (nebo list comprehension), nečekám, že se bude dít něco zásadního kromě filtrování/spracování dat.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jednak jsem to zmiňoval jako rychlou ukázku C-G jakožto konstruktu pro<br>
studenty (kde se navc netvoří profesionální kód), za druhé mohu dostat<br>
všechny potřebné informace vč. stavových a za třetí... kam se vám poděl<br>
EAFP (<a href="https://docs.python.org/2/glossary.html" target="_blank">https://docs.python.org/2/glossary.html</a>)?<br>
<span class=""><br></span></blockquote><div><br></div><div>Tu poznámku o EAFP jsem nepochopil.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
> Mimochodem v python3 uz reduce ani neni builtin (byl presunuty do<br>
> functools) a i Guido to vidi obdobne:<br>
> <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=98196" target="_blank">http://www.artima.com/weblogs/viewpost.jsp?thread=98196</a><br>
<br>
</span>S tím souhlasím, nic proti. Sám jsem psal, že ji používám zřídka.<br>
<br>
Děkuji za diskusi, štvete mě jen malinko. :-)<br></blockquote><div><br></div><div>Cílem určitě nebylo někoho štvát. Měl jsem pocit, že nabízím konstruktivní názor. Pokud to tak nebylo, omlouvám se.<br>-- <br></div><div>Radek <br></div></div></div></div>