Zajímavý python: dočasný adresář

8.8.2014 15:32 | Přečteno: 1461× | | poslední úprava: 8.8.2014 15:32

Jednoduché zadání: udělat si pro práci s ghostscriptem dočasný adresář v /tmp. Člověk by řekl že na takové prkotině není moc co zkazit nebo zlepšit, ale python docela překvapil.

O knihovně tempfile vím, takže jsem šel celkem najisto a podle očekávání našel i funkci na vytvoření adresáře. Kupodivu to nijak neřeší úklid po práci, a k ještě většímu podivu nic takového neumí ani jinak spolehlivý os.path. Ne že bych neuměl natlačit os.path.walk() do unlink(), ale pamětliv Zlatého Pravidla Trivialit ("když to nenajdeš ve standartní knihovně, znamená to že jsi špatně hledal") jsem polechtal googla a našel modul shutil. Chtěl bych potkat člověka co ten název vymyslel. I když jinak mám standartní knihovnu celkem prokouknutou, na tohle bych tedy nepřišel.

Protože nevím jaké nečekané překvapení může vypadnout z ghostscriptu, chci aby byl úklid automatický. Nabízí se tedy myšlenka sdrátovat to dohromady context managerem. Ale když máme celou "práci" ve dvou jednoduchých příkazech, zdá býti trochu overkill tahat do toho ještě další objekt. Nejsem přece Javista Java mi ale něco připoměla – jmenovitě contextmanager() z contextlib o kterém jsem si svěho času pomyslel že popis "dekorátor který z generátoru udělá contextmangager" zní jako něco obzvláště vypečeného z dokumentace JDKčka. A taky že taková blbost přece nemůže mít rozumné uplatnění… to jsem se ale šeredně zmýlil.

@contextlib.contextmanager
def TempDir():
    path = tempfile.mkdtemp()
    yield path
    shutil.rmtree(path, True)

with TempDir() as tmpPath:
    …
    subprocess.check_call(["ghostscript", "-o", os.path.join(tmpPath, "%s.jpg")] + args)
    …

Poznámka: ne, fakt to není nic objevného. To že je to takhle jednoduché se mi právě líbí.

Poznámka pro pythonisty kteří nehoví kontext managerům: příklad si z toho neberte, tohle je dost nestandartní způsob jak to dělat.

Pro zvědavé nepythonisty: v podstatě to funguje tak že na začátku with bloku se zavolá to co je před yield a na konci ten zbytek. Hlavní vtip je v tom že i když vystřelí výjimka, tak po sobě program způsobně uklidí a pak se výjimka propaguje dál. (V produkčním kódu se úklid nechá ladícím příznakem vypnout.)        

Komentáře

[alfonz]

modul shutil používám docela často hlavně právě na mazání. Je to docela příjemné hlavně používané funkce jsou copytree() a rmtree(). Sem tam ještě make_archive.

Podobné použití už jsem pár krát zkusil, ale kvůli čitelnosti jsem to zas tak často nepoužil.

[petr_p]

Pořád mi to přijde neohrabané. Třeba v Perlu stačí napsat:

{
  my $tmpPath = File::Temp->newdir;
  IPC::Run3::run3(['ghostscript', '-o', File::Spec->cat($tmpPath, '%s.jpg'), @args]);
}

Vtip je v tom, že metoda newdir() třídy File::Temp vrátí objekt, jehož destruktor standardně (lze potlačit) vyrobený adresář smaže. A destruktor se zavolá v okamžiku, kdy program opustí blok. (Včetně vyvolání výjimky.)

[rADOn]

Takhle je udělaný v pajtní standartní knihovně dočasný soubor, ale adresář ne. Nejspíš je to něco ještě z dob před 2.5, pacz řešit to destruktorem je v jazyce bez bloků (ve smyslu oboru platnosti) beztak neideální.

[kralyk z abclinuxu]

Zajímavé.

Je vidět, že RAII není jen pro low-level jazyky (C++,...), ale je užitečné i ve skriptech. Teď ještě, aby to došlo i návrhářům jazyků, kteří místo toho tvrdošíjně lpí na finally...

[rADOn]

Ja bych si tipnul že návrhářům jazyků se RAII líbí do okamžiku než začnou řešit co se stane když po výjimce během prokousávání se zásobníkem vystřelí další výjimka. Hlavní důvod proč to v tomhle případě lze napsat takhle primitivně je že si můžu dovolit chyby při úklidu ignorovat.

[kralyk z abclinuxu]

No, RAII sice s exception safety úzce souvisí (zejména např. v C++), ale jinak je to v podstatě nezávislý koncept. Např. Rust má RAII, ale nemá výjimky...

[Seraph]

Destruktor nesmí vyhodit exception. Musí vždy proběhnout. To je nepsané pravidlo v C++. Díky tomu je RAII skutečně bezpečný nástroj při stack unwindingu. Ovšem pokud někdo nacpe exception do destruktoru ... jeho chyba. Při bližším ohledání je vidno že RAII je unikátní vlastnost objektového paradigmatu. Takže naopak nerozšíření RAII je znak v nejlepším případě ignorance.

[johniez]

V c++11 je to psane pravidlo :)

[Miriam]

A přesně na takovýhle příkladech si člověk uvědomí krásy OOP. O pár řádků kódu víc, ale o pár desítek let déle to vydrží a pár desítek minut času při příštím setkání mi to ušetří.

[pavel]

A přesně na takovýhle příkladech si člověk uvědomí krásy funkcionálního programování. O pár řádků kódu míň a o pár desítek let déle to vydrží a pár desítek minut času při příštím setkání mi to ušetří.

[Seraph]

BUG corrected

[xkucf03]

V Javě na to máme rozhraní AutoCloseable. Takže napíšeš:

try (TřebaAdresář zdroj = kdeSeVezme()) {
   // tady s tím zdrojem něco děláme
   // a může vyletět výjimka
}

Je jedno, jestli je tam i catch blok a jestli nějaká výjimka vyletí – zdroj se prostě na konci try bloku (nebo při chybě) sám korektně uzavře (zavolá se jeho metoda close()).

[kralyk z abclinuxu]

Ze zvědavosti: Co se stane, když výjimku vyhodí kdeSeVezme()?

[Seraph]

Zdroj nebyl zabrán (zabrání selhalo), tak tím pádem ho není třeba uvolňovat.

[kralyk z abclinuxu]

No jasný, ale jde mi o to, jestli to je stejné, jako kdyby ta exception byla vyhozena v těle try, nebo ne.

[xkucf03]

Zdroj se ani nevytvoří, takže ho není potřeba zavírat.

A výjimku můžeš zachytit v daném try/catch bloku:

try (Connection c = DriverManager.getConnection("…")) {
    // děláme něco se spojením
} catch (SQLException e) {
    // ošetříme výjimku
}

nebo v nějakém vyšším nebo ji poslat nahoru.

[kralyk z abclinuxu]

Takže když ti ten getConnection() vyhodí SQLException, tak to skočí na ten catch block a tělo try se nevykoná, chápu to správně?

[xkucf03]

ano, viz odkaz níže

[xkucf03]

Ještě jsem to trochu rozepsal v blogu: Java a princip RAII (CADRe) známý z C++

[xkucf03]

Přidal jsem do výběru

Ale k věci – na tom:

@contextlib.contextmanager
def TempDir():
    path = tempfile.mkdtemp()
    yield path
    shutil.rmtree(path, True)

mi prostě nějak nesedí, že kód pro vytvoření (konstruktor?) a kód pro úklid (destruktor?) jsou v jednom bloku a na základě nějaké magie se udělá část bloku teď a část potom. Víc se mi líbí explicitnější vyjádření, kde mám jednu metodu/blok pro vytvoření a druhou pro úklid.

[Seraph]

To je normální, Python řeší věci ... po svém. Ostatně Java taky. K čemu RAII -> máme GC, ať se procesor nenudí (a hlavní výhoda objektového paradigmatu ať jde klidně do pekla).

[kralyk z abclinuxu]

Je sranda pozorovat, jak k tomu ty jazyky stejně nakonec skoro všechny nějak dokonvergujou, dokonce i ta Java (pro kterou zřejmě okopírovali syntaxi ze C#). Nicméně i C++ v tomhle ohledu prošlo vývojem - viz např. scope guard idiom s lambda funkcí.

[pavlix]

To je normální, Python řeší věci ... po svém.

Pokud vím, tak context manager interface jde v Pythonu triviálně implementovat třídou. To, že někdo vymýšlí cypoviny typu contextlib.contextmanager na tom nic nemění.

[rADOn]

Jo, je to sice pár ušetřených řádků ale většina věcí se dělá líp objektem. A proto jsem tam taky schválně napsal že tohle není standartní způsob.

[Bystroushaak]

Heheh, nedávno jsem použil skoro to samé. Pěkně sepsáno.

[chrono]

yield path a shutil.rmtree(path, True) by malo byť v try: finally, pretože ak tá funkcia subprocess.check_call vyvolá výnimku, ten súbor sa nevymaže.

[mirec]

Hmm, o contextlib-e som nevedel. Elegantný spôsob zneužitia yield

[xkucf03]

Co máte všichni s těmi liškami?

[Heron]

Někdo lišky, někdo tygry, někdo démony .

[mirec]

Nejak som v poslednej dobe dosť často stretával jednu líšku (ospravedlňujem sa za kvalitu ale nemal som zrkadlovku so sebou, je to fotené pár metrov za domom kde bývam), naživo je to krásne zviera tak som si povedal prečo nie ako avatar. Chameleóna už dávno nemám (keby niekoho zaujímalo chameleóny sa nedožívajú ktovie akého veku).

[neklan]

Musim se priznat, ze prave proto nemam pythone rad. A to bych si i byl schopen odpustit nasilny prechod z 2.7->3+

proste tohle je strasna prasarna - nic vic k tomu nereknu

jinak autor blogu se navazel do javy. Kde je nejen try/condition ale i finnaly block. Prominte za expresivni vyjadreni, ale uz uplne vidim toho kokota, jak hleda v 250k radkovem kodu, kde ma yield....

proste nekteri jsou nepoucitelni.

(a nerikam, ze java je nej... neni. ale nedovoli podradnym radobyprogramatorum az tak moc prasit.)

[chrono]

Aj Python ma finally, navyše pre konštrukciu with x as y sa normálne používajú metódy __enter__ a __exit__ (a tá konštrukcia použitá v blogu sa používa len ak daná trieda nemá podporu pre with).

[Bystroushaak]

Vzdy pobavi, kdyz java koder poucuje pythonisty o cistote kodu :)

[pavlix]

A nejlépe na základě zkreslených informací o (současném) Pythonu.

[rADOn]

Podle toho co pise xkucf03 vyse o AutoCloseable ma zkresleny informace i o Jave…

[kralyk z abclinuxu]

a nerikam, ze java je nej... neni. ale nedovoli podradnym radobyprogramatorum az tak moc prasit.

Už jsem se vyrovnal s tím, že tenhle mýtus je ve světě Javy světě prakticky nevymýtitelný... Je to něco jako ta teorie o tom, že letadlo letí proto, že vzduch na vrchní straně křídel proudí rychleji - naprostý nesmysl, ale i velmi chytří lidé ho neustále opakují...

[xkucf03]

Už jsem se vyrovnal s tím, že tenhle mýtus je ve světě Javy světě prakticky nevymýtitelný.

Četl jsem javovský kód pro ne moc dobrých programátorech a člověk si občas zanadává, to jo, ale nakonec se s tím popereš, refaktoruješ to, opravíš – dá se na tom stavět. A pak jsem měl zdrojáky v pythonu nebo pascalu, které bylo lepší zahodit, prokousat se sám zadáním nebo to vymyslet znova, než se je pokoušet opravovat.

[kralyk z abclinuxu]

Tak tos asi ještě nenarazil na dostatečně zprasený Javovský kód...

[xkucf03]

Pošli nějaký příklad

[kralyk z abclinuxu]

V javovským týmovým školním projektu kamarád prohlásil, že se postará o síťovou vrstvu. Co z něj vypadlo bylo něco příšernýho... Aplikace na všechno otvírala vždy nové spojení se serverem a všechno se přenášelo na několikrát (resp. na mnohokrát), takže zhruba 80% traficcu bylo redundantní. Styl zápisu stál taky za houby - by použit javovský antipattern "na všechno si vytvoř nový objekt"... Řešením byl přepis.

[xkucf03]

A za jeho blbost může Java jak?

Já neříkal, že v Javě nejde psát špatně, ale aspoň je vidět, co je špatně a dá se v tom vyznat, víš, co by to mělo dělat, je z toho lépe vidět ten záměr autora, dá se to přepsat, refaktorovat (aniž by se ti to rozsypalo pod rukama).

[kralyk z abclinuxu]

A za jeho blbost může Java jak?

Nijak. Já neříkal, že za to může Java.

Já neříkal, že v Javě nejde psát špatně, ale aspoň je vidět, co je špatně a dá se v tom vyznat, víš, co by to mělo dělat, je z toho lépe vidět ten záměr autora, dá se to přepsat, refaktorovat (aniž by se ti to rozsypalo pod rukama).

To jsou kecy. Situace je v podstatě stejná jako u ostatních jazyků, výjimku by tvořil snad jen assembler. Tobě to v Javě připadá jasnější/přehlednšjí, protože Javu (zřejmě) znáš nejlépe.

[kralyk z abclinuxu]

Ok, abych byl fér, tak je pravda, že když se započítá učící křivka, tak ta Java z toho asi vyjde poměrně dobře (a např. python imho taky). No ale žádné velké záruky čitelnosti to zase nejsou

[rADOn]

Java možná za jeho blbost nemůže ale podporuje ji. Když někdo napíše krávovinu v céčku nebo pythonu nebo čemkoliv, tak je to krávovina. Když někdo napíše krávovinu v Javě, tak je to obložený tolika objektama, rozhraníma a mezivrstvama že je to vlastně "entrprajs".

[Heron]

Tohle se bohužel projevuje i v mnoha jiných prostředích, kdy vývojáři mají pocit, že když pro každý nový projekt nepoužijí 40 nových technologií (a na každý projekt pro jistotu jiných, protože ta půl roku stará technologie, co se použila minule, už je obsolete), tak nejsou dostatečně in.

[R]

Poznam "entrprajs" sracky, kde je cesta natvrdo nastavena na c:\blabla... A cele je to zabalene v setup.exe, aby si to mimo Windows nahodou neskusil spustit.

Ale da sa to nainstalovat cez Wine a nasledne spustit s OpenJDK. Cesty s c:\ Linux prezije, jednoducho vytvori subor s tym c:\ v nazve.

Zdravim programatorov firmy EMC.

[xkucf03]

Co je na Windows "entrprajs"? Vždyť je to spotřební odpad. Enterprise jsou velké servery, na kterých běží Unix, Solaris, OpenVMS, HP-UX, AIX nebo dneska čím dál víc GNU/Linux a provozují se nad tím velké relační databáze (ne jejich parodie), LDAPy o desítkách milionech záznamů, Java EE a podobné věci.

[rADOn]

Jo ale na to musíš mít něco v hlavě. Když to naprasíš v Javě tak je to entrprajs protože je to přece multiplatformní. A ještě můžeš dělat ramena na ty idioty kteří nikdy neviděli program na sto tisíc řádků. I když jsou jako správný entrprajs z valný části zbytečný

[Pavel Stárek]

Entrprajs, neentrprajs, Java má jednu obrovskou výhodu. A totiž že ty enterprajs věcičky jsou v ní dobře podporovány a podporují je i všelijaká IDE. Potřeboval jsem pro jednu aplikaci udělat server s webovou službou (SOAP). Jako aplikační server jsem zvolil JBoss a v Netbeansech jsem to měl naklikané za pár minut a mohl jsem se v klidu věnovat vlastní implementaci té věci. Jsem převážně Pythonista, ale nebyl jsem schopen najít něco rozumného pro Python (Pythoního klienta pro SOAP ano, na to používám knihovnu suds).

[podlesh]

Já neříkal, že v Javě nejde psát špatně, ale aspoň je vidět, co je špatně a dá se v tom vyznat, víš, co by to mělo dělat, je z toho lépe vidět ten záměr autora, dá se to přepsat, refaktorovat (aniž by se ti to rozsypalo pod rukama).

Ne, ne, ne, špatně. Pointa je úplně jinde: i zprasenou aplikaci lze provozovat. TO je to slavné "enterprajs".

Prostě se kód hodí někomu trochu schopnějšímu a ten do termínu nějak zafixuje ty nejhorší problémy a doplní pár ohejbáků a rovnáků na ohejbáky. Pak se při instalaci přihodí se párkrát víc paměti (a/nebo víc serverů), v nejhorším se dá do cronu restart jednou za čas v noci a oficiálně oznámí "plánovaná odstávka" - a hotovo. Zákazník platí (možná brblá že je to pomalé a vůbec, ale platí). Všichni se poplácají po rameni za úspěšně dokončený projekt, možná i prémie budou. A už se může připravovat další projekt - při troše štěstí to bude projekt "přepis sračky A"

Rozdíl oproti aplikaci v C/C++ je ten, že zprasená aplikace chcípe na segfault. Pokud je to jednou týdně tak je to ještě fajn (a pokračuje se podle scénáře výše), ale pokud každých 10 minut tak je to konečná. Musí se to přepsat. Projekt není dokončen (rozhodně ne včas), zákazník neplatí (a naopak má nárok na slevu), prémie nejsou dolů a budou i padat hlavy. V managementu (tam to hodně záleží na politikaření) a možná i mezi programátory. Tam to ale záleží zda seženete lepší.

Pravdou je, že je to trochu off-topic: python je v principu stejně vhodný pro enterprise jako Java či .NET, možná někdy i vhodnější. IMHO by se velmi dobře uchytil, kdyby někdy nastartovala kladná zpětná vazba (tj. bylo hodně pythonistů zajímajících se o korporátní praxi).

PS: Z vlastní praxe samozřejmě nemám dostatečný vzorek abych mohl generalizovat, ale informace z doslechu mi to jen potvrzují. A kromě toho, povyšování vlastních zážitků na obecně platné pravdy je na tomto fóru standardní praxí

[xkucf03]

Prostě se kód hodí někomu trochu schopnějšímu a ten do termínu nějak zafixuje ty nejhorší problémy a doplní pár ohejbáků a rovnáků na ohejbáky.

Takže se mnou vlastně souhlasíš Vývoj v Javě je efektivní a funguje – cílem totiž je, vejít se do termínů a rozpočtu a dodat aplikaci, která dělá to, co bylo v zadání. Jestliže tohoto cíle jde v Javě dosáhnout¹, tak Java prostě je vhodný jazyk.²

Rozdíl oproti aplikaci v C/C++ je ten, že zprasená aplikace chcípe na segfault.

Javovská aplikace zase může padat na NullPointerException, nebo třeba čtení indexu mimo rozsah pole, nebo neúspěšné přetypování… ale většinou bude snazší (a tím pádem levnější) takovou chybu nalézt³ a opravit.

Pravdou je, že je to trochu off-topic: python je v principu stejně vhodný pro enterprise

V jedné firmě jsme měli jak Javu, tak C++, vyvíjely to různé týmy a úspěšně fungovalo oboje – myslím, že oboje jsou vhodné jazyky/platformy. Ale o tom Pythonu mám dost pochybnosti.

V Pythonu se neproklikáš skrz zdrojáky, kam potřebuješ, hůř se zjišťuje, co to vlastně dělá a kde bys měl provést opravu/úpravu. Trávit každé odpoledne v debuggeru tě brzo přestane bavit a jdeš se radši zeptat původního autora aplikace⁴. Průšvih je, když ten člověk pak odejde a tobě zbude jen hromada dynamického kódu, který kdesi uvnitř dělá něco špatně. To se fakt radši budu hrabat v Javě po Indech nebo v C/C++.

_{[1] a dokonce s větší pravděpodobností než v mnohých jiných jazycích
[2] navzdory tomu, že někdo může považovat Javu za příliš ukecanou nebo omezenou
[3] už z výpisu chyby vidíš třídu, metodu a řádek, kde k ní došlo a odkud se to volalo
[4] tzn. budou nad tím zabíjet čas dva lidi, které firma platí, a toho druhého budeš brzdit v jeho současné práci}

[Bystroushaak]

V Pythonu se neproklikáš skrz zdrojáky, kam potřebuješ

Proč by ne?

hůř se zjišťuje, co to vlastně dělá

To je imho nesmysl.

Trávit každé odpoledne v debuggeru tě brzo přestane bavit

Ono je dobré vzpomenout, že python debugger (pdb) je REPL. Z mé zkušenosti plyne, že najít tam bug je podstatně jednodušší a zabere to obvykle méně času.

[mirec]

Ešte doplním, že na konzolové veci je pdb fajn. U webových som si celkom zvykol na werkzeug. Z webových sa mi ešte o niečo viacej páčil wdb (povinne pozrieť gif ), ale oproti werkzeugu otvára nový tab v browseri ...

[rADOn]

V Pythonu se neproklikáš skrz zdrojáky, kam potřebuješ, hůř se zjišťuje, co to vlastně dělá…

Vidíš, já bych řekl že je to přesně naopak. V pytohnu když nějakej kód něco dělá, tak je napsanej tak aby to dělal, a je to vidět protože nic jiného tam prostě není. Protože "simple is better then complex". V Javě to bude obložené tunami zbytečné syntaxe a obestavěně vrstvami zbytečné abstrakce které nejsou k tomu aby program něco dělal, ale jen uspokojují nějakou buzeraci stran kompileru nebo něčí představu o "jediném správném programování". Java je v tomhle možná lepší než C++ páčž jsou tyhle představy aspoň nějak jednotný, ale těžko mě přesvědčíš že promyšlená a zdokumentovaná zbytečnost je přehlednější než žádná zbytečnost

Pokud máš problém pochopit fungování nějakýho pajtního kódu a není to něco opravdu složitýho (v jakémkoliv jazykce), tak vsadím koláč proti psímu sucharu že chyba není v pajtnu ale v javovských idiomech a konstrukcích který tam někdo ze zvyku zatáhl. Dělat ze všeho za každou cenu objekty, singletony, zbytečný strukturování, nebo dokonce, pámbu s námi, gettery a settery. V práci tohle vídám pořád, anžto tu je spousta přeučených céčkařů a ze zkušenosti vím že pokud stejná funkčnost není v pajtnu desetkrát míň kódu než v C++, tak je něco špatně. (A taky desetkrát pomalejší, o tom si nebudem nic nalhávat…)

[xkucf03]

V pytohnu když nějakej kód něco dělá, tak je napsanej tak aby to dělal, a je to vidět protože nic jiného tam prostě není.

To už se bavíš o úspornosti na úrovni jednotlivých řádků, konstrukcí – tedy na té mikroúrovni, která není až tak důležitá. Důležité (a to, o čem jsem psal) totiž je najít to místo (třeba dvacet řádků), kde máš hledat – a v tom ti dynamičnost jazyka hází klacky pod nohy. V Javě může tím místem být třeba 25 řádků místo 20, ale vtip je v tom, že toto místo najdeš mnohem snáze a spolehlivěji.

simple is better then complex

Vtipný překlep Docela často se setkávám s tím, že někdo přijde s nápadem: „jednodušší je lepší“ – a následně, ve výsledku je to spíš složitější.

V Javě to bude obložené tunami zbytečné syntaxe a obestavěně vrstvami zbytečné abstrakce které nejsou k tomu aby program něco dělal

Ta abstrakce není jen tak pro nic za nic, dává ti větší flexibilitu, umožňuje např. měnit implementace různých věcí, aniž bys musel zasahovat do zbytku programu. Často ho ani nemusíš překompilovávat a jde to udělat na úrovni konfigurace.

Na Javě se často kritizují továrny (factory – návrhový vzor). Tady je dobré si uvědomit, že jde vlastně o funkcionální programování. Továrna je ve své podstatě funkce, která generuje další funkce nebo objekty. Továrnu/funkce můžeš odněkud dostat a použít ji, aniž bys musel řešit, kde se vzala a co je uvnitř – prostě pracuješ s předem definovaným rozhraním a víc tě nemusí zajímat.

které nejsou k tomu aby program něco dělal, ale jen uspokojují nějakou buzeraci stran kompileru nebo něčí představu o "jediném správném programování".

Hned vedle máš pěkný příklad – Python vs. XSLT. V Pythonu potřebuješ 17 řádků (+2 na konci) na balastní kód, který nic pořádného nedělá, nesouvisí s byznys logikou dané úlohy. Zatímco v XSLT máš v 17 řádcích celý program. V Pythonu je celý program na 38 řádků.

Nemám rád porovnávání počtu řádků kódu, nepovažuji to za úplně důležitý ukazatel. Ještě zajímavější je ten obsah. V XSLT máme 5 řádků ze 17, které představují šablonu výsledného dokumentu – tato šablona odpovídá výsledku jak strukturou (wallet/folder/password), tak formou (XML) a je tedy dobře čitelná a srozumitelná. Další 4 řádky ze 17 představují FOR cykly, jejichž přítomnost je daná zadáním (snažil jsem se co nejvíc napodobit tu pythoní implementaci – jinak to šlo taky udělat jen přes šablony, bez FOR cyklů). Další 2 řádky jsou prázdné. A jen 4 řádky se dají označit jako hlavička/zápatí, jakýsi nezbytný a ne příliš užitečný kód. Nepotřebuješ žádné pomocné proměnné (a neustále se koukat nahoru do kódu, co v nich vlastně je uložené) a nepotřebuješ znát žádné zvláštní metody a konstruktory, protože šablona a výsledek k sobě mají velmi blízko, vidíš to na první pohled.

Pokud máš problém pochopit fungování nějakýho pajtního kódu a není to něco opravdu složitýho (v jakémkoliv jazykce), tak vsadím koláč proti psímu sucharu že chyba není v pajtnu ale v javovských idiomech a konstrukcích který tam někdo ze zvyku zatáhl.

Tak jsi právě prohrál koláč. Ten kód, o kterém jsem mluvil, psal člověk, který nesnášel Javu, přišla mu příliš ukecaná, staromódní a těžkotonážní, a byl nadšeným propagátorem Pythonu.

Dělat ze všeho za každou cenu objekty, singletony, zbytečný strukturování

Jako že bychom místo objektů používali radši seznamy a mapy a textové klíče? No tak to by bylo ještě lepší! V tom už by člověk nenašel vůbec nic, byla by to ještě větší hromada hnoje, chatrná skládačka, která na sebe brzo přestane pasovat (textové klíče se rozpadnou, na každé straně programu budou jiné, a těžko se to zjistí¹) a v tom se člověk neprokliká už vůbec nikam. Můžeš leda tak grepovat zdrojáky a ručně zkoumat, co je ten správný textový klíč, co je náhodná shoda a co naopak nenalezená shoda (např. dynamicky skládaný klíč z několika částí, který grepem nenajdeš).

pokud stejná funkčnost není v pajtnu desetkrát míň kódu než v C++, tak je něco špatně.

Tohle není dané jazykem, ale knihovnami. Jestliže má někdo tento pocit, tak je to iluze způsobená tím, že pro Python má k dispozici lepší knihovny než pro C. Pokud budeš mít podobně vysokoúrovňové knihovny pro Python, Javu, C, C++, tak není důvod, aby se délka programu zásadně lišila – nějaké odchylky tam budou, ale rozhodně ne desetinásobné – spíš tak v jednotkách procent nebo třeba 10 %.

_{[1] tady asi někdo namítne, že se mají psát unit testy – v tom případě si k počtu řádků programu přičti ještě počet řádků testů, které musíš napsat jen pro kontrolu toho, co ti v jiných jazycích ohlídá zadarmo kompilátor – a už to najednou tak úsporně nevypadá, řádků kódu je v součtu víc}

[kralyk z abclinuxu]

V Javě může tím místem být třeba 25 řádků místo 20, ale vtip je v tom, že toto místo najdeš mnohem snáze a spolehlivěji.

No tak to bych teda chtěl vidět nějaké podložení tohoto výroku. V Javě osobně nenajdu věci o nic snáz než v Pythonu, možná i hůř, vzhledem k oblíbenému zvyku Javistů zaobalovat objekty do jiných objektů a ty do dalších objektů atd., používat všelijaké AbstractFactoryVisitorProviderAdapter a podobné srandy. Stalo se mi asi u dvou nebo třech Java projektů, že jsem narazil na celé adresáře plné nějakého boilerplate kódu / balastu a vlastní logika aplikace byla zahrabaná kdesi mezitím nebo taky úplně jinde...

[xkucf03]

To je spíš otázka konkrétního programátora než jazyka. Samozřejmě, že nepotřebného balastního kódu je škoda. Pro Javu jsou i nástroje a metriky, které ti odhalí mrtvý nebo nedosažitelný kód, nebo třeba upozorní přílišnou složitost.

Ale jde o to, že i navzdory těmto neduhům se k té implementaci nakonec v IDE proklikáš, buď přímo přes metody nebo si zobrazíš seznam tříd implementujících dané rozhraní nebo potomků. Je to jedno kliknutí a spolehlivě je najdeš. Kdežto u dynamického jazyka je to prostě horší. Moje osobní zkušenost je taková, že je lepší se jít zeptat původního autora (pokud je tedy k dispozici), který si pamatuje, kam danou funkcionalitu napsal, než se to pokoušet hledat sám (on by to taky v cizím kódu jen tak nenašel). Jedna část toho projektu měla cca 20 tisíc řádek a druhá cca 80, to prostě není jako když si lidi píší skripty na jednu obrazovku a podle toho soudí. Naštěstí většinou stačilo hledat v té menší části, ale ani tak to nebylo jednoduché.

[Bystroushaak]

Kdežto u dynamického jazyka je to prostě horší. Moje osobní zkušenost je taková...

Jen aby bylo jasno - týká se tvoje osobní zkušenost pythonu, nebo čeho vlastně?

[xkucf03]

jj, byl to Python. A když to srovnám s programem v Javě (který měl tak 6× víc řádků), tak v tom se dalo zorientovat a vyznat lépe.

[rADOn]

No vidis, prave jsi nam prozradil ze v realnem zivote je pomer mezi javou a pythonem 6:1 a ne 10% jak jsi psal vyse A jestli ten python psal nejaky preuceny (byt treba nadseny) javista tak to nebude nic moc...

[xkucf03]

Linux má 50× víc řádků než jEdit → programy v C jsou 50× větší než programy v Javě!

[rADOn]

Psal jsi "A když to srovnám s programem v Javě..." tak pocitam ze to srovnavas s reimplementaci tehoz nebo aspon s necim podobnym.

[xkucf03]

Ne, byly to různé aplikace, ale chtěl jsem tím říct, že v javovském programu se stejným (nebo i vyšším) počtem řádků se IMHO dá orientovat lépe. Já vím, že to nejde úplně zobecňovat, ale tohle je prostě můj aktuální dojem a hodnocení Java vs. Python. Co se týče kvality programátorů, tak ani ten javovský kód nepsali nějací špičkoví programátoři a kvalita byla dost „různorodá“.

[Heron]

Spíš zda to opravdu není tím, že Javu prostě dobře umíš.

Nejsem programátor, ale když jsem psal v Javě, tak jsem také pozoroval tlak onoho jazyka na takové ty "enterprise" věci, patterny apod (přesně jak psal Kralyk), takže nakonec ta aplikační logika byla schovaná za devatero horami interfaců, proxy, fasád a apod.

Naproti tomu Python tento tlak nemá, vede přirozeně k minimalizaci a ta standardní knihovna s tím tak nějak počítá. A hlavě nenutí hned od počátku používat třídy, takže rychlý skriptík se napíše během pěti minut. Když se potom rozroste, lze ty funkce lehce povýšit na metody v nějaké třídě.

Nechci v žádném případě porovnávat Javu a Python a vyvyšovat jeden nad druhý. Javu jsem měl hodně rád (dojem mi zkazil Oracle), stejně jako mám rád Python. Jen píšu své pozorování a dojmy.

[kralyk z abclinuxu]

Ale jde o to, že i navzdory těmto neduhům se k té implementaci nakonec v IDE proklikáš, buď přímo přes metody nebo si zobrazíš seznam tříd implementujících dané rozhraní nebo potomků.

Detektivní práce to ale bude tak jako tak. Osobně když potřebuju něco hledat v nějakém projektu (třeba se jedná o desetitisíce řádek), tak ačkoli to třeba je jazyk proklikatelný v IDE (C/C++/Java/...), tak často stejně nakonec skončím u grepu et al. + IDE v podstatě jen pro zobrazení a navigaci

[xkucf03]

Netbeans mají funkci „Find in projects“, což je taková kombinace grepu a findu s GUI, řekneš, v jakých souborech hledat (přípony, regulární výraz) a co hledat (text, regulární výraz…) a hlavně se pak z výsledků proklikáš na zdrojáky, jsi pořád v IDE a nemusíš si kopírovat nebo opisovat názvy souborů z konsole. Ale moc to nepoužívám – většinou se totiž dá dobře skrz zdrojáky navigovat pomocí funkcí, které tomu zdrojáku rozumí, chápou syntaxi a neberou ho jen jako text.

[kralyk z abclinuxu]

Podobnou funkci taky občas používám, ale konzole je konzole

[rADOn]

...a v tom ti dynamičnost jazyka hází klacky pod nohy. V Javě může tím místem být třeba 25 řádků místo 20, ale vtip je v tom, že toto místo najdeš mnohem snáze a spolehlivěji.

Mozna hazi. Ale v Jave tech radku nebude 25 ale 200 v peti ruznych objektech.

simple is better then complex

Vtipný překlep Docela často se setkávám s tím, že někdo přijde s nápadem: „jednodušší je lepší“ – a následně, ve výsledku je to spíš složitější.

To cituju klasika. Cele je to trochu delsi:

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

Cim dele se prganim zivim, tim vic zjistuju ze jsou to zlata slova.

Na Javě se často kritizují továrny (factory – návrhový vzor). Tady je dobré si uvědomit, že jde vlastně o funkcionální programování. Továrna je ve své podstatě funkce, která generuje další funkce nebo objekty. Továrnu/funkce můžeš odněkud dostat a použít ji, aniž bys musel řešit, kde se vzala a co je uvnitř – prostě pracuješ s předem definovaným rozhraním a víc tě nemusí zajímat.

Ja vim co je fabricka metoda. V pythonu je pouzivam bezne, jen pri tom nemusim psat tuny zbytecneho kodu jen abych takzvane objektovemu jazyku vysvetlil ze funkce je take objekt. Vetsinou staci jedno rovnitko. Ostatne ted kdyz se java naucila lambdy a uzavery tak se snad pohnou ledy.

Hned vedle máš pěkný příklad – Python vs. XSLT.

Jo to je moc pekny priklad. Jenom jsi nejak zapomel zminit kolik kodu by to bylo v jave. Jinak to nic nerika - ja jsem uplne stejnym zpusobem v predchozi praci vymenil desitky radku javy za jeden (slovy: "1") radek awku, ale nevyvozuju z toho vic nez ze pro dane zadani je awk uzitecny. Za stejnou cenu jako XSLT - ze je nepouzitelny pro cokoliv jineho.

Pokud máš problém pochopit fungování nějakýho pajtního kódu a není to něco opravdu složitýho (v jakémkoliv jazykce), tak vsadím koláč proti psímu sucharu že chyba není v pajtnu ale v javovských idiomech a konstrukcích který tam někdo ze zvyku zatáhl.

Tak jsi právě prohrál koláč. Ten kód, o kterém jsem mluvil, psal člověk, který nesnášel Javu, přišla mu příliš ukecaná, staromódní a těžkotonážní, a byl nadšeným propagátorem Pythonu.

Klidne, ale nejdriv ukaz ten kod.

Dělat ze všeho za každou cenu objekty, singletony, zbytečný strukturování

Jako že bychom místo objektů používali radši seznamy a mapy a textové klíče?

Jako ze objekt reprezentuje nejakou skutecno entitu nebo funkcnost, ne jen magickou formulku kterou musis dokola opisovat aby te kompiler nezjebal. Ale tohle ti asi nevysvetlim, to neni v jazyku ale v hlave. Pohrdave se vyjadrujes o seznamech a mapach, pritom to jsou perfektni objekty. A to cemu rikas objekt je v pythonu zase jenom mapa. Pritom se to chova daleko vic objektove nez Java, kde jsou objekty v podstate jen tecky ve jmenech.

Schvalne, jak bys teda v pythonu napsal singleton?

[podlesh]

To je velmi pochybný příměr. Ve skutečnosti je to spíš jako "chleba padá vždy namazanou stranou dolů".

[pavlix]

Nikdy jsem nepochopil, k čemu ten contextlib.contextmanager wrapper je. Pokud chci vytvořit objekt implementující with API, přijde mi mnohem čistší, jednodušší a přehlednější ho vytvořit pomocí třídy než pomocí generátorové funkce. V definici té třídy na první pohled vidím, které příkazy patří ke které akci a žádný wrapper nepotřebuju.

[Bystroushaak]

Ušetří ti to práci. Pokud píšeš jen nějaký kludge, který má udělat danou věc jednou/dvakrát a pak bude zapomenut, tak to má význam.

[pavlix]

Ušetří ti to práci.

Nevšiml jsem si, spíš mám pocit, že ojebávání programu syntaktickými hříčkami mi práci dříve či později přidělá.

[pavlix]

I když ona to není ani tak syntaktická hříčka jako úplně normální obfuskace.

[Bystroushaak]

No vsak píšu, že se to týká scriptů, které napíšeš ve chvíli, kdy prostě jen něco potřebuješ udělat, ale je jedno jak toho dosáhneš a budeš to dělat jednou, či maximálně dvakrát. Když to například píšeš interaktivně do konzole, nebo tak.

[pavlix]

Běžně interaktivně v konzoli vytvářím context managery. Navíc to mnozí berou jako standard a všem to doporučují a používají to v příkladech a řešeních na různé dotazy. Výsledek můžeš sledovat i zde na ábíčku. Možná se to nemělo stát součástí standardní knihovny.