První dojmy z Pythonu (diskuse)

[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í.