První dojmy z Pythonu

27.12.2005 15:50 | Přečteno: 2260× | Jen tak | poslední úprava: 27.12.2005 16:19

Už dlouho pokukuji po tom, že zapojím do své práce programovací jazyky jako Python, nebo Ruby. Celkem dlouho jsem studoval různé tutoriály těchto dvou jazyků, abych se rozhodl, který z nich si vyberu. Nakonec to bylo celkem jednoduché, rozhodl jsem pro Python. Důvody byly dva. Jednak dnes si nechci nic začínat s jazykem, který nepočítá již v jazyce s Unicode řetězci, což je bohužel případ Ruby. Druhý důvod je spíše emocionální, neobjektivní a nespravedlivý. Ruby mi některými svými způsoby připomínalo Perl, což je jazyk, jehož syntaxi a některé způsoby vysloveně nesnáším a tento můj rasistický postoj se bohužel promítá i do Ruby.

Protože nerad zdlouhavě teoretizuji, rozhodl jsem se jít hned do praxe a napsat pár jednoduchých skriptů v Pythonu, abych ho vyzkoušel na jednoduchých úlohách. Přečetl jsem si pouze základní tutoriál, abych se seznámil se základní syntaxí Pythonu, jeho zvláštnostmi a pak jsem jel naostro. Zde přináším postřehy z tohoto testování Pythonu.

První bylo střetnutí s vývojovým prostředím IDLE, což má být standardní vývojové prostředí pro vývoj Pythonu. V zásadě prostředí fungovalo k mé spokojenosti a nemohu mu nic podstatného vytknout.

Ok, začal jsem psát první skript. Co mám povídat, čím víc jsem psal, tím víc se mi Python líbil. Odkojen mnoha jazyky stylu C/C++, Java, C#, PHP, a dalšími jsem zjistil, že v Pythonu jdou věci tak snadno! Ten jazyk mi začal připadat jako kamarád, který se mi snaží opravdu pomoci. Nenutí mě k ďábelským trikům, když chci dokázat něco složitějšího, jako C/C++ (doporučuji prohléhnout knihovnu boost a jeho implementaci práce s datumem a časem pomocí nejvyšších prvků C++ - jenom půj megabajtu zdrojáků ). Neklade mi překážky typu "musíš se mi absolutně přizpůsobit a jenom já vím co je pro Tebe dobré a pokud chceš něco, co já neumím jsi barbar" jako Java. A taky nezažívám traumata typu "ani porovnávání dvou řetězců nezvládne jednoduše porovnat dva řetězce" jako PHP.

Na druhé straně problémy taky byly. Například jsem neodhadl chování konstrukce print, které má jednoduše vypsat své operandy oddělené čárkou. Co jsem nečekal je, že mezi jednotlivé výpisy Python vkládá mezeru, což se mi skoro nikdy nehodilo. Sakra, kterej vůl takové chování konstrukce print vymyslel? A proč? Takže jsem konstrukci print začal v Pythonu ignorovat jako neužitečnou a špatnou a řeším to jinými způsoby.

Pokud bych měl dál posoudit první kontakt s Pythonem, tak mě též překvapil manuál k Pythonu. Manuál je vynikající a je v něm všechno podstatné. Pokud budete používat HTML verzi, nic vám nebude chybět. Já jsem část svých pokusů s Pythonem odehrál i na Windows (chtěl jsem vyzkoušel multiplatformost Pythonu), kde jsem používal CHM verzi manuálu a jeho rejstřík nestál za nic. Mnohdy jsem si dal vyhledat v rejstříku určitá hesla, kde mě to odkazovalo na naprosto nesmyslná místa, a místo kde dané heslo skutečně bylo jsem nakonec vždycky musel vyhledat fulltextovým vyhledáváním. Ale jinak musím říci, že manuál je dobrý, je v něm vše, co jsem potřeboval a byla na něm odvedena dobrá práce.

Další překvapení jsou standardní knihovny Pythonu. Dovolil bych si vznést předpoklad, že vznikaly dost neookordinovaně a na jejich rozhraní je to bohužel hodně znát. Tím neříkám, že by byly špatné, ale jaksi ... ehm ... to není ono ... ehm .... Každý modul má trochu jiný styl. Asi jsem moc zmlsaný dobrým návrhem knihoven Javy. No pokud bude zájem, můžu se o knihovnách Pythonu rozpepsat někdy později více.

Ještě jsem se okrajově zajímal o Jython, což má být implementace Pythonu na virtuální stroj Javy. Měl jsem z něho rozpačitý dojem, protože spousta věcí z Pythonu tam nefuguje, leckteré standardní knihovny Pythonu mají problémy a vůbec mě přišlo, že autor chce jít spíše cestou používání Javovských knihoven. Existuje ještě komplementární projekt IronPython, který generuje kód pro .NET framework, který jsem ale nezkoušel. Veskrze ale těmto projektům nedůvěřuji, protože si myslím, že přešít dynamicky typovaný jazyk s vícenásobnou dědičností, jakým je Python na virtuální stroj, který je připraven pro statické jazyky musí vést jedině ke značným kompromisům.

Celkově mám dojem z Pythonu velmi dobrý a velmi příjemně mě překvapil. Určitě ho budu minimálně pro své věci používat. Docela by mě zajímalo, zda existuje uplatnění pro Python v praxi, třeba v nějakém zaměstnání, či jinde.

       

Komentáře

[Bones]

Jako Pythonista Ti preju hodne uspechu a spokojenosti s Pythonem.

K modulum: To je pravda. Moduly delali ruzni lide, neexistuje pro ne neaka norma, ktera by urcovala jakym zpusobem je psat. Obecne je zvykem je delat objektove, definovat tridy a v nich funkce, venku pak promene a tak, aby se vyuzily vyhody Pythonu. Nicmene ke snad kazdemu modulu existuje (vetsinou) dobra dokumentace, tak neni problem pomerne rychle se naucit modul ovladat.

[Kyosuke]

Knihovna není dokonale systematická asi v žádném jazyku.

Jinak, Ruby 2 se určitě v mnoha směrech polepší, sám autor napsal už před časem sebehanu. Perlismy jsou tak jako tak deprecated, IMHO to bylo především na přetáhnutí perlistů. Pak jim někdo určitě strčí do ruky Coding Style Guide...

[Miloslav Ponkrác]

Ruby mě stále zajímá, ale určitě ho budu chtít zkusit až s verzí s Unicode. Mimochodem, ta sebehana by mě zajímala. Je na ní nějaký odkaz?

Perlismy jsou možná deprecated, ale některé věci se už těžko změní. Třeba jen to, že metoda vrací hodnotu posledního výrazu považuji za něco, co může vést k velmi těžko nalezitelným chybám a pochybuji, že to v Ruby 2 bude jinak.

[Kyosuke]

Nevím, vracení posledního výrazu podle mě není perlismus, ale lispismus. Pokud vám na tom záleží, vracejte vždycky hodnotu přes return a metody bez returnu střílejte na potkání.

http://www.rubyist.net/~matz/slides/rc2003/index.html

[Miloslav Ponkrác]

Asi máte pravdu, LISP byl první.

Ten odkaz na tu prezentaci je moc pěkný. Moc díky za něj. Skoro jsem pochopil, že autor Ruby se naprosto nebojí totálně Ruby překopat. Zvláště ta pasáž kdy "multiple values" chce odvodit jako třídu od Array mi přišla docela odvážná.

Abych řekl pravdu, líbí se mi, jak se Ruby stará o svojí budoucnost. Moc by se mi líbilo, kdybych podobnou péči o svou budoucnost viděl u Pythonu.

[trancelius]

Taky můžete předat print parametry v jediném operandu (op1+op2), to bude bez mezer (ale type conversion si budete muset ohlídat sám)

K praktickému využití: Gentoo Portage je z velké části v Pythonu, Seznam.cz má taky monstrozní část webu postavenou na pythonu (např. chat) a pro svou školu jsem v Pythonu napsal systém pro správu sítě... a díky pythonu to netrvalo ani den :) takže jako jazyk pro blitzschnell vývoj je Python dokonalej

[Bubak]

Dik za informace. K takovemu pokusu jsem se jeste neodhodlal. Mohl bys treba jeste naznacit, jak je to s rychlosti? Jak se programuje GUI a jak to pripadne funguje ve Windows? Jak funguji graficke veci (cmarani nejakych car v okne apod.)? Pripadne porovnani s Javou (dejme tomu jednoduche kresleni)? Nechci samozrejme veci z manualu, spis postrehy programatora (dle tvych prispevku te povazuji za zkuseneho vlka).

Sveho casu (kdyz jsem zacal psat vlastni forms server a vyvojove prostredi) jsem se pokousel rozbehnout GNU Forms, (abych se mrknul, jak to vypada a jestli by nebylo lepsi pridat se k tomuto projektu, pripadne ho jenom zacit pouzivat) a problemy, ktere jsem pri tom mel, me odradily... Mozna jsem je prikladal Pythonu neopravnene, ale byl prvni na rane.

Take mi trochu vadi nutnost instalovat (na Windows) dalsi runtime. A myslim, ze jsem tehdy narazil take na nutnost instalovat novejsi verzi i na Linuxu, coz mi nalady nepridalo. Ale je fakt, ze tyto zkusenosti bych datoval nekam kolem roku 2000.

[trancelius]

Programování GUI jsem ještě nenakousl, atm si oprašuju znalosti ncurses (textová UI) - většinou jsem někam přihlášenej přes ssh, takže textová stačí... u GUI toolkitů je python modul většinou jen hromada wrapperů na C implementaci, takže pokud znáte např. GTK+, PyGTK vám bude určitě připadat povědomě. Čmárání čar - pygame.draw (btw, PyGame je asi nejlepší knihovna/modul co jsem kdy viděl). S Javou zkušenosti nemám :)

Co se týče použití na Windows, já se k té platformě dostanu jen občas, ale zatím mi vše fungovalo OK (třeba pygame bez problému). Vím, že např. curses na Windows nejedou (kvůli jejich parodii na terminál) a provádět meziprocesovou komunikaci pomocí soketu taky asi nebude nejlepší nápad.

[Miloslav Ponkrác]

Odpovím hned. GUI si nechávám jako další příspěvek, až posbírám ještě pár zkušeností. GUI lze řešit v Pythonu hned několika způsoby. O dojmech z GUI v Pythonu chci napsat další příspěvek.

Rychlost Pythonu je jasná. Pokud vezmu základní implementaci Pytonu zvanou CPython, tedy to, co se normálně používá, tak je v zásadě Python o něco pomalejší, než Java. Nicméně přesto Python pomalý není. Nutno říci, že se intenzívně pracuje na tom, aby byl Python ještě rychlejší. Slyšel jsem třeba o projektu Psyco, který má zrychlit Python, ale neskoušel jsem ho a nemám s ním zatím žádné zkušenosti. Koneckonců i projekty IronPython a Jython by také měly přinést rychlejší Python. Ale jak říkám, Python pomalý není, většinu věcí jsem testoval na starém vykopávkovém počítači Pentium 200 MHz a Python běžel v pohodě.

Co se týká ale GUI a kreslení čar v okně, apod.., tak se mi Python naopak zdá rychlejší, než Java, ale konečný verdikt si nechám ještě na později, až to pořádně protestuji. Zatím je ještě asi brzo, abych něco s určitostí tvrdil. Takže to ber zatím jako první předběžný postřeh. Je to tím, že Javu hodně zpomalují knihovny, které jsou psané zase hlavně v Javě. Zatímco Python se mi zdá, že používá grafické knihovny psané v rychlejších jazycích, jako je C++, apod..

Jinak na Windows nemusíš instalovat runtime. Existuje prográmek py2exe, který Ti z Pythonovských zdrojáků udělá exe program a ten pak můžeš bez problémů spouštět i bez runtimu. To mi věř, že právě o tyhle věci jsem se zajímal. Bohužel nemohu poskytnout praktické zkušenosti s py2exe, mám ho stažený, ale vyzkoušet se ho teprve chystám.

[trancelius]

Psyco mám a používám, to zrychlení (hlavně teda u Portage, ta je v některých fázích dost náročná) je velmi dobře vidět. Funguje to podobně jako JIT compiler u Javy

Vykreslování (v pygame) rychlé je, protože se z většiny odehrává v SDL (a ta využívá opengl akceleraci)

Py2exe - přímo s ním zkušenost nemám, ale projekt Outer Space ho úspěšně využívá (a můžu potvrdit, že to funguje jak má)

[Spike]

Já nemám s psyco dobré zkušenosti. Portage IMHO nijak znatelně nezrychlí, Gajim zabírá dvakrát více RAM (120 MB virtuální paměti a nějakých 40 fysické je na IM klient HODNĚ).

Každopádně zkušenosti a koncepty z psyco by se měly promítnout do PyPy.

[trancelius]

Na hodně pomalým stroji Psyco zrychlí viditelně - celeron 300 MHz s 52 MB dostupné RAM (na rychlé mašině to znát opravdu není)

[Bubak]

Diky (vsem), celkem jste me potesili. Doufam, ze se mi podari najit dost casu, abych Python opravdu vyzkousel na vlastni kuzi.

většinu věcí jsem testoval na starém vykopávkovém počítači Pentium 200 MHz a Python běžel v pohodě

A tohle me tesi jeste vic. S Javou na podobnem stroji mi to nejak neklapalo.

[Bones]

Krome py2exe, ktere je jednoduche, existuji dalsi "kompilatory", viz. http://www.py.cz/VytvareniExeSouboru. cx_Freeze je i pro Linux!

[Daniel Kvasnička ml.]

pythonu jsem propadl a neminim na to nic menit

toolkitu je hodne, wxPython (wrapper kolem wxWidgets), o kterem pisu diplomku, je dobry. Ma dobrou dokumentaci a je opravdove multiplatformni (na rozdil treba od cisteho GTK. wxPython pouziva GTK pouze v Linuxu, na Win a Mac ma nativni look). PyQt je take kvalitni a je rychly. Qt ma navic vyhodu, ze pro nej existuje kvalitni nastroj pro design GUI (QtDesigner ...a dalsich par kvalitnich programu nam Trolltech nadelil), zato pro wxWindows jsem tak kvalitni nastroj zadarmo nenasel. Pouzivam wxGlade, ale to spis jen na zacatek aplikace, pak rucne :/ Neda se s QtDesignerem srovnavat. Boa-Constructor je to nejvetsi psycho, co jsem videl...proste mi absolutne vubec nevyhovuje. No flame please. Pak je tu samozrejme PyGTK, nezkousel jsem. Nevidim duvod, proc bych pouzival PyGTK, kdyz mam wxPython. Mozna je rychlejsi? Nevim. Pak Tkinter, na kterem jede to IDLE. Ten uz umira...doufam Je na Linuxu fakt hnusnej IMHO samozrejme... Asi toho je i vic, IronPython asi taky, .NET/Mono je i na vyvijeni multiplatformnich GUI, ne? Esi to chapu...

Vybirat je z ceho, Python i prace na GUI s nim je krasa

[Miloslav Ponkrác]

Mockrát díky za zkušenosti. Tohle jsem přesně potřeboval.

Já bych jen dodal, že při svém zkoušení GUI jsem automaticky vyndal vše založené na Qt z důvodů pro mě nepřijatelné licenční politiky.

Knihovnu wxWidgets znám už z práce s C++, takže tak nějak zhruba vím, kde jsou její silné a slabé stránky. V C++ mě wxWidgets celkem vyhovovaly, akorát mě zase neskutečně štvaly svým C++ rozhraním, které degradovalo C++ ohromným způsobem, a třeba ošetřování chybových stavů wxWidgets byla neskutečná noční můra, pokud se to mělo dělat pořádně. Doufám, že tyto problémy ve wxWidgets nejsou, a že se mohu spolehnout na výjimky, ale to teprve zjistím.

PyGtk bych vyzkoušel rozhodně chtěl.

Tk rozhraní bych taky úplně neodepisoval, alespoň ne bez toho, než si to vyzkouším.

V zásadě chci vykoušet vše, co se mi bude zdát trochu licenčně a funkčně přijatelné z tohoto seznamu:

http://wiki.python.org/moin/GuiProgramming

a pak se rozhodnout.

[trancelius]

Neberte to jako pokus o flame, berte to jako "correct me if I'm wrong":

není Qt licencovaná pod GPL 2 ? Pokud váš software bude pod GPL-2 taky, není problém... je to GPL knihovna jako každá jiná; pokud byste nechtěl uvolnit software pod GPL, Trolltech vám nabízí řešení v koupi non-GPL licence (GPL-only knihovnu by jste v druhém případě použít nemohl)

[Miloslav Ponkrác]

Ano Qt je licencovaná pod GPL 2. Ale já nechci věnovat spousty času do učení se práce s grafickou knihovnou jenom proto, abych pak byl omezen na to dělat programy strikně pod GPL licencí.

Chci dát možnost uvolnit svoje zdrojové kódy pod jakoukoli licencí. Mě se třeba osobně daleko více líbí licence BSD, případně publikování jako public domain. Chci, aby lidé měli možnost některé mé kódy použít, aniž by museli být nesvobodně vázáni na jednu licenci. Pokud začnu používat Qt knihovnu, jsem o tuto svobodu připraven. Moje svobodné rozhodnutí je, že to neakceptuji.

[Miloslav Ponkrác]

Ano Qt je licencovaná pod GPL 2. Ale já nechci věnovat spousty času do učení se práce s grafickou knihovnou jenom proto, abych pak byl omezen na to dělat programy strikně pod GPL licencí.

Chci dát možnost uvolnit svoje zdrojové kódy pod jakoukoli licencí. Mě se třeba osobně daleko více líbí licence BSD, případně publikování jako public domain. Chci, aby lidé měli možnost některé mé kódy použít, aniž by museli být nesvobodně vázáni na jednu licenci. Pokud začnu používat Qt knihovnu, jsem o tuto svobodu připraven. Moje svobodné rozhodnutí je, že to neakceptuji.

[Daniel Kvasnička ml.]

V zásadě chci vykoušet vše, co se mi bude zdát trochu licenčně a funkčně přijatelné z tohoto seznamu:

http://wiki.python.org/moin/GuiProgramming

Vida! V Pythonu se da pouzit i eclipsi SWT...to jsem ani nevedel, podivam se na to. tedy ne, ze by byl Eclipse kdovijak svizny - i kdyz ja osobne jsem tou absenci sviznost ochoten zaplatit za jeho kvalitu. Ale podle me kazda opravdu multiplatformni knihovna, ktera si da tu praci a vypada na danych systemech (vice mene) nativne, stoji za vyzkouseni

[Miloslav Ponkrác]

Upřímně řečeno, sice to do Pythonu nepatří, ale já bych dneska do SWT nešel, pokud by mě nemučili. SWT je bastl nad bastly.

[Daniel Kvasnička ml.]

mozna proto je Eclipse tak line

ale podivam se na to stejne jako vy na Tk

[Miloslav Ponkrác]

klidně se podívejte, ale je to bastl, který podle mě nestojí za pozornost. za časů, kdy jsem se o SWT zajímal to nemělo ani data grid a tím pádem to bylo k ničemu. a o problémech s SWT bych mohl vyprávět, ale jestli si chcete rozbít čumák, udělejte to

[Daniel Kvasnička ml.]

jo a rychlost je u GUI IMHO vetsi, nez u Javy/Swingu. Alespon u PyQt je to podle me znat. I wxPython je podle me rychlejsi. Jinak nevim....

[petr]

Nenutí mě k ďábelským trikům, když chci dokázat něco složitějšího, jako C/C++ a co tak list comprehension :)

[trancelius]

>>> data = range(20)
>>> neco = [x for x in data if x%2 == 0]
>>> print neco
[0, 2, 4, 6, 8, 10, 12, 14, 16, 18]

to je ono ne ?

[Kyosuke]

To je ta největší sranda. Python se chlubí tím, jakou skvělou vymoženost (list comprehensions) převzal z funkcionálních jazyků, funkcionální jazyky zase od užívání list comprehensions zrazují, že je to příliš imperativní styl...

[trancelius]

Nikdo vás nenutí to používat... je lepší tu možnost mít a nepotřebovat ji, než ji potřebovat a nemít

[Kyosuke]

Jde o to, že dotyčné funkcionální jazyky místo list comprehensions vybízejí k používání funkcí vyššího řádu, což je přesně to, co v Pythonu 2 v omezené míře je a v Pythonu 3 nebude. ::)

V Pythonu to samozřejmě má smysl, je to docela hezký syntaktický cukr, mně jde jen o komično té situace.

[fakenickname]

Předem se omlouvám za dotaz, nejsem totiž programátor. Jediné co trochu ovládám je HTML a CSS a trochu BASHe. Zajímá mě, jaký výstup vlastně Python má. Může z něj vypadnout binárka? Třeba .exe nebo linuxová binárka? Jak těžké je udělat v pythonu nějaký GUI program? Rád bych se konečně naučil trochu programovat a udělal pár prospěšných prográmků (například DVDShrinx ;)).

[Daniel Kvasnička ml.]

Zajímá mě, jaký výstup vlastně Python má. Může z něj vypadnout binárka? Třeba .exe nebo linuxová binárka?

Pro windows je tu py2exe, pro Linux nevim o zadne takove moznosti, ktera by vytvarela uplne klasicke binarky. Co ale vim je, ze pythonsky program prispusteni vytvori .pyc soubor, coz je neco mezi klasickou binarkou a zdrojakem. Takovy polotovar. Jak moc to ovlivnuje rychlost, to nevim.

Correct me if I'm wrong.

Jak těžké je udělat v pythonu nějaký GUI program?

to je strasne relativni pojem... lehke to podle me neni nikdy s zadnym jazykem. Nejakou praci to chce. Ale verte mi, ze Python vam to svou povahou ulehci jak jen to bude mozne

[trancelius]

py2exe jen sbalí dohromady python a všechny použité moduly, takže to nativní binárka úplně není

.pyc soubor je bytecode Pythonu a automaticky se vytvoří pouze z modulu (jeho import uloží bytecode, aby se pozdější nahrávání urychlilo). Na byte-kompilaci python souboru se používá volání compiler.compileFile().

[pok]

Zdravim, zkuste: print "soucet cisel %d a %d je roven *%d*" % (a, b, c) a je to bez mezer :)

Jeste muj posterh k dokumentaci. Jak je mozne ze jenom me pripada tak stracne neprehledna? Vsude kde o Pythonu neco ctu ji vychvaluji, ale po pravde to nechapu - nevim proc, asi mi neco unika :)))

[Martin Beránek]

Jak je mozne ze jenom me pripada tak stracne neprehledna? Vsude kde o Pythonu neco ctu ji vychvaluji, ale po pravde to nechapu - nevim proc, asi mi neco unika :)))

me asi taky neco unika, podle me je ta dokumentace strasna a neprehledna - zlatej javadoc (noflame).

[Miloslav Ponkrác]

to jste mě ještě více postrašil. právě jsem zjistil, že print dokonce předaný řetězec nějak interpretuje a hledá v něm procenta a snaží se podle nich formátovat. uf! print je velmi nebezpečná věc, budu si muset na to dávat pozor.

P.S.: Upřímně řečeno, jako referenční příručka Pythonovský manuál nemá zase takových kvalit, ale má šanci stát se dobrou příručkou. Je v ní leccos, od tutoriálu, po syntaxi jazyka, přes C API, a tak dál. Tak to má být. Já vždycky rostu, když dostávám strojově generované příručky generované pomocí javadoc/oxygen a podobných nástrojů. Mě se daleko více líbí příručky psané ve stylu manuálu k PHP, kterou považuji za daleko užitečnější a líbí se mi, že Pythonovský manuál má tendenci jít stejným směrem.

[rADOn]

to jste mě ještě více postrašil. právě jsem zjistil, že print dokonce předaný řetězec nějak interpretuje a hledá v něm procenta a snaží se podle nich formátovat. uf! print je velmi nebezpečná věc, budu si muset na to dávat pozor.

neco jako

print "odpoved na otazku %s je %i" % ("zivot,vesmir a vubec", 42) 

??? to je prave ta krasa jednoduchosti kterou na pythonu miluju - neni to vubec vlastnost prikazu print (a tedy vyjimka z vyjimky) ale proste vtipne pouzity pretizeny operator (a tedy standartni vlastnost jazyka), jakmile pochopite logiku te veci (a pokud znate printf formatovaci znaky z C) je to trivialitka.

oddelovani parametru prikazu print je imho spis ladici zalezitost - kdyz je potreba nekde rychle neco vyblejt bude to fungovat bez dodatecne namahy. specialnejsi chovani muze stejne vyzadovat kazdy jine takze se mi zda spravne nesnazit se zavdecit vsem coz z principu nejde a misto toho poskytnout prostredky jak dosahnout co nejprizpusobivejsiho vystupu s co nejmensi namahou.

btw pripomina mi to awk a vsadim se ze nekde v sys knihovne bude promena kterou pujde ten oddelovac nastavit, jako je v awku promena OFS.

[Miloslav Ponkrác]

Ale já to chápu. Stejným způsobem jsem kdysi vyráběl formátování streamů v C++ pomocí operátoru%. Takže logika věci je mi jasná.

Chápu, že je správné nechtít se zavděčit všem, ale ptám se, komu se zavděčili tou mezerou vkládanout mezi výstupy konstrukce print? Já se obávám, že naprosto nikomu.

Jinak přísahám, že pokud v nějaké další verzi Pythonu bude k dispozici proměnná, která bude určovat oddělovač mezi výstupy konstrukce print, tak upravím zdrojáky interpetu Pythonu tak, že sprovodím konstrukci print totálně ze světa. V případě použití konstrukce print se bude hlásit syntaktická chyba. Ten současný bordel s konstrukcí print bohatě stačí, natož zavádět ještě další.

Jediné čisté řešení, které existuje v konstrukcoi print je přidat definici oddělovače do každé konstrukce, tedy něco ve stylu

oddelovac.print parametry

[Shadow]

Vysvětleno a obhájeno je to zde.

[Shadow]

A ještě možná přijde vhod tato relevantní část dokumentace na Wikibooks.

[Miloslav Ponkrác]

Co se týká té obhajoby na vkládání mezer mezi výstupy print, tak jsem si jí přečetl, ale jediný pocit, který z ní mám je, že se snaží udělat z nouze ctnost. Prostě mě to nepřesvědčilo, že to vkládání mezery má nějaký přínos, respektive její přínos je bohatě přebit četnými nevýhodami tohoto řešení, abych byl přesný. Navíc jsem z toho dokumentu pochopil, že zdaleka nejsem sám, komu chování print přijde jako nenormální.

Jasně, že jsem si našel řešení, ale považuji ho jen za obcházení nedokonalostí Pythonu. Prostě print jsem totálně sprovodil jako nepoužitelný a používám něco jako:

import os

def safe_print(*params):
  for p in params:
    os.sys.stdout.write(str(p))

safe_print("a",3,23.4,"\n")

Používám svojí funkci safe_print a print je pro mě neexistující věc.

[trocha pravdy]

Pozde, ale co kdyz to nekdo bude nekdy cist:

a=['ahoj','cau']
for x in a: print x

vystup:
ahoj
cau

for x in a: print x, #carka na konci!
vystup:
ahoj cau

[Lukáš Zapletal]

Java jako zářný příklad návrhu knihoven bych raději nedával Viz například Effective Java od J. Blocha... :-P

[Miloslav Ponkrác]

Zářný příklad určitě ne, ale knihovna Javy je jedna z těch lepších, pokud mohu posoudit zkušenosti se standardními knihovnami z různých programovacích jazyků. Spíše mám nějak dojem, že dobrá standardní knihovna je u programovacích jazyků spíše vzácná věc. Mohu uvést třeba naprosto katastrofální stav z hlediska standardních knihoven u jazyka C++, který tento jinak mnou oblíbený programovací jazyk značně snižuje. Na druhé straně třeba knihovny C# mají leccos lépe, než Java. Veskrze u většiny dalších programovacích jazyků jsou knihovny značně různorodé.

Jinak s tou knihou Effective Java jsem neměl tu čest se setkat.

[pavlix]

Python je fajn a uplatnění v praxi čím dál víc v Česku narůstá.

Sám už jsem se na pythoních projektech podílel (v jednom projektu byl prosazen z části díky mně).

Spíš mám pocit, že chybí dobří programátoři než uplatnění.