Přejít k navigační liště

Zdroják » Různé » Znám jen PHP. Jak napíšu webovou aplikaci v Pythonu?

Znám jen PHP. Jak napíšu webovou aplikaci v Pythonu?

Články Různé

Jste otrávení z psaní webů v PHP a při posedávání v kavárnách slýcháte od svých kamarádek, že kdybyste se naučili Python, bude váš život krásnější, plnější, barevnější, prostě dokonalý od kořínků ke konečkům? Teď je ta pravá chvíle vykročit z komfortní zóny a zkusit to! Pojďme se podívat na to, jak v Pythonu začít s webem.

Nálepky:

Následující text je volným překladem článku Python FAQ: Webdev, jehož autorem je Eevee a je zde zveřejněn se souhlasem autora. Článek jsem tu a tam aktualizoval, doplnil, nebo obohatil o nějakou tu větu.

Úplně nejjednodušší odpověď na otázku z nadpisu by bylo: “Přestaň číst tento článek, podívej se na Flask, a začni něco tvořit.” Někdy je ale lepší věci trochu rozvést.

Následující text však není návodem – předpokládám, že čtenář se zvládá učit z dokumentace. Je to přehled poměrů, jaké v současnosti vládnou ve webovém vývoji v Pythonu. Je to úvod pro někoho, kdo chce s Pythonem začít a nevyzná se.

Začínáme

Zcela zřejmě je k webovému vývoji v Pythonu potřeba mít nainstalovaný Python. Ujistěte se, že váš Python je verze 2, protože ve verzi 3 byly provedeny některé zpětně nekompatibilní změny a ne zcela všechny knihovny byly už přepsány tak, aby fungovaly na obou verzích.

Pro instalaci knihoven se používá pip. Na Linuxu si jej snadno pořídíte jako balíček – v Ubuntu třeba pomocí sudo apt-get install python-pip. pip je package manager pro Python – slouží k instalaci, odebírání a aktualizaci všech knihoven. Je to tedy ekvivalent nástroje Composer, jenž se používá ve světě PHP. Upřednostňujte pro instalaci Python knihoven pip před jakoukoliv jinou cestou, protože jen tak budete mít k dispozici jejich nejnovější verze.

Ve výchozím stavu instaluje pip knihovny přímo do systému, ale k tomu je např. v Linuxu potřeba sudo, neboli administrátorské oprávnění. Navíc, máte-li v systému nějaký program napsaný v Pythonu (a takových bývá na Linuxu hodně), můžete globálním zásahem nechtěně ovlivnit jeho závislosti a rozbít si jej. Je možné instalovat knihovny do vlastního domovského adresáře pomocí pip install --user ..., ale ještě lepší je mít knihovny nainstalované separátně pro každý projekt, na kterém pracujete – jen tak lze mít na různých projektech různé verze stejné knihovny a zabránit jakýmkoliv kolizím. Nástroj virtualenv přesně toto řeší – umožňuje jedním příkazem vytvářet izolované instalace Pythonu. Tento koncept je tak rozšířený a oblíbený, že už se stává přímo součástí nejnovější verze Pythonu.

Framework

První věc, kterou musíte vyřešit, je spojit nějak váš kód s prohlížečem. Začínáte-li s PHP, nejjednodušší cestou je nainstalovat Apache a předhodit mu nějaký adresář se soubory, které má servírovat do světa. V Pythonu, stejně jako ve větších PHP projektech, je řešením nějaký webový framework.

Frameworky mívají většinou podobné workflow:

  1. Nainstalujete framework jako knihovnu. Nejlépe přes pip.
  2. Vytvoříte skeleton nového projektu, tedy kostru adresářů a souborů. Složitost těchto skeletonů se různí. V již zaniklých Pylons člověk skončil se slušnou hromádkou jakéhosi záhadného kódu, který bylo potřeba manuálně aktualizovat novými verzemi frameworku. Flask je tak jednoduchý, že nepotřebuje vůbec žádný skeleton. Někde mezi nimi je Pyramid, kde kostru tvoří jen běžný startovní kód, jejž byste museli stejně napsat ručně, kdybyste skeleton nepoužili.
  3. Nakonfigurujete pár věcí, např. databázi.
  4. Spustíte vývojový server. Vývojový server je většinou jednoduchý konzolový program, který spustí vaši webovou aplikaci bez toho, že byste museli mít nějaký opravdový těžkotonážní HTTP server (jakým je třeba už onen zmiňovaný Apache). Vývojové servery umí detekovat změny ve vašem kódu a znova si jej načítat, vypisují do konzole nezachycené výjimky, logované zprávy a podobné informace vhodné pro debugování aplikace. Tato funkce se v PHP vyskytuje od verze 5.4.0 a skrývá se pod přepínačem php -S.
  5. Programujete!

Nu dobrá, jaký framework si však vybrat? Na výběr jsou stovky možností, ale jen několik je těch opravdu oblíbených a běžně používaných.

Já mám rád Pyramid, který se nachází někde ve zlatém řezu mezi minimalismem a plně vybaveným monolitem (batteries-included). Je to celkem mladý počin, ale vyvinul se ze dvou starších a používaných projektů. Výsledek je dobře navržený, dobře zdokumentovaný a poměrně přehledný. Jednoduchá aplikace nevyžaduje žádné velké psaní, k dispozici jsou skeletony, s nimiž lze práci rychle odstartovat. K tomu všemu je Pyramid snadno upravitelný a rozšiřitelný, díky čemuž roste i nabídka doplňků.

Pro ještě rychlejší start je vhodný Flask (pozn. překl. – ten mám rád zase já). Tento mikroframework je jednoduchý, jak jen to jde, ale přitom nabízí šílené množství doplňků a možností rozšíření, díky nimž na něm není problém vystavět i velmi komplikované aplikace. Flask je navržen tak, aby sice poskytoval poměrně rozumnou sadu nástrojů v základu, ale zároveň aby vám přitom nepřekážel a do ničeho vás příliš nenutil.

Bottle je podobný jako Flask, je však ještě jednodušší. Má jeden jediný soubor a nemá žádné závislosti na dalších knihovnách. Jestli je to dobře nebo špatně, to nechám na čtenáři. Chcete-li si vytvořit drobný, třístránkový web nebo toužíte-li si Python jen vyzkoušet, určitě stojí Bottle za vyzkoušení. Mnohdy se také objevuje jako výuková pomůcka v návodech pro úplné začátečníky.

Na druhé straně spektra se nachází Django, masivní bestie původně navržená pro backendy ve stylu CMS a podobně obsahově bohaté weby. Má obrovský ekosystém doplňků, přičemž už v základu poskytuje všechno možné od šablon až po ORM. Existují k němu hory dokumentace, článků, návodů, aj. komunitně tvořených informací. Často je Django považováno za ekvivalent Ruby on Rails. Nevýhodou je, že někdy nemusí být úplně příjemné nutit jej dělat věci, které se mu dělat nechtějí… Pro začátečníka to také může být možná až zbytečně těžké kladivo – učící křivka nemusí být úplně krátká.

web2py… existuje… Ehm, no – vlastně o něm ani nic dalšího nevím. Údajně sám od sebe vkládá proměnné do jmenných prostorů vašich modulů, což je dost prasárna. Takže pokud vám není jedno, že já si o něčem myslím, že je to prasárna, tak tento framework nepoužívejte. Anebo klidně… vždyť je to jedno.

Existují i další frameworky, třeba Twisted nebo Tornado, které jsou založené na asynchronních voláních a používají se například když chcete pracovat s mnoha paralelními požadavky, ale pro začátečníka přicházejícího z PHP to asi není úplně ono.

Dříve existoval a používal se mod_python, modul do Apache, který byl myšlenkou spřízněný s mod_perl, ale už se dávno nevyvíjí. Prosím, nepoužívejte jej.

Nakonec je také dobré se zmínit, že je možné napsat webovou aplikaci v Pythonu „ručně“, bez použití nějaké knihovny, ale pocit při psaní takového kódu se velmi blíží k něčemu jako je porod dikobrazích paterčat. Není to ani rychlejší, ani naučné, ani nijak moc užitečné. Netrapte se tím a nezkoušejte to.

Mé doporučení? Pokud si chcete jen vyzkoušet Python, chopte se Flasku a postupně si na něj přikládejte, co potřebujete, až když to potřebujete. Pokud máte už vymyšlený nějaký webík a chcete ho uvést rychle do provozu, použijte scaffolding v Pyramid a začtěte se do jeho výpravné dokumentace. Toužíte-li do měsíce dělat weby v Pythonu jako placenou práci, vrhněte se na Django.

Routing

Zatímco čisté PHP spouští na základě URL konkrétní soubor, webové aplikace napsané v Pythonu mají sklon „vlastnit“ celý adresář (nebo i celou doménu). Přiřazování konkrétních URL určitému kódu je tedy o něco pružnější a je obvykle spravováno tzv. routingem. Kdo pracuje s nějakými PHP frameworky, koncept routingu určitě zná, ale pojďme si jej připomenout.

„Routy“ (z anglického route, mn. č. routes) jsou parametrizovaná URL, jako například tato:

/users/{name}
/companies/{id}/products
/blog/{year:\d\d\d\d}/{month:\d\d}/{day:\d\d}/{title}

Když k té první routě připojíte funkci a v prohlížeči půjdete na /users/eevee, funkce se spustí a parametry pro ni budou k dispozici v podobě {"name": u"eevee"}.

Některé frameworky (jako Pyramid) jdou v tomto směru ještě o kousek dál – místo propojování routy přímo s funkcí musíte dát routě nejdříve název a ten teprve spojit s funkcí. Je to práce navíc, ale výhodou je centrální seznam všech stránek v aplikaci. Také se potom dá URL vytvořit i zpětně z názvu routy a parametrů, díky čemuž lze všechna URL měnit na jediném místě v aplikaci bez toho, aby to ovlivnilo cokoliv dalšího. Překlep při vývoji navíc místo „stránky 404“, kterou objeví až uživatel, rovnou způsobí chybu.

Každý webový framework v Pythonu využívá nějakou obměnu takovéhoto routingu, ačkoliv konkrétní syntax a implementace se vždy trochu liší. Některé v určitých ohledech zjednodušují práci, např. předpřipravenými nástroji pro vytváření RESTful rout, nebo umožňují napsat si routy od základů úplně podle svých představ.

Životní cyklus HTTP požadavku

HTTP požadavek obvykle volá nějakou funkci (vybranou routingem) a předává jí objekt request.

Rozhraní takového objektu závisí na konkrétním frameworku, ale jeho obsah je vždy podobný – data z dotazu, cookies, hlavičky, atd. Vezměme například Request objekt z knihovny webob, který zahrnuje následující:

  • request.GET a request.POST jsou „multislovníky“ s daty z dotazu. (Multislovník vrátí jednu hodnotu pro request.GET['foo'], ale přes metodu getall() umožní dostat se ke všem hodnotám pod stejným klíčem. Takové chování se hodí např. pro uložení dat, jež měly v URL tvar ?foo=42&foo=69.)
  • request.params je multislovník kombinující obojí z předchozího bodu.
  • request.cookies je slovník s cookies.
  • request.headers je slovník s HTTP hlavičkami, ale s klíči, které nejsou citlivé na velikost písmen.
  • request.is_xhr podává informaci o tom, zda je přítomna hlavička X-Requested-With: XMLHttpRequest, jíž se běžně identifikují AJAXové požadavky z knihoven jako je např. jQuery.

Popis chování request objektů bývá zpravidla důkladný, takže většinou stačí nakouknout do dokumentace příslušného frameworku a najít si to důležité, co zrovna potřebujete.

Když je vaše aplikace hotova s tím úžasným něčím, co měla na práci, potřebujete nějak odeslat HTTP odpověď. Obvykle máme možnost buďto si sami sestrojit nějaký Response objekt (včetně HTTP hlaviček a dalších ručních serepetiček), nebo můžete rovnou vrátit kus HTML a zbytek nechat na výchozích hodnotách. Velice zřídkakdy však potřebujete tvořit odpověď sami, protože pro všechny obvyklé potřeby (jako např. i odesílání JSON) mají frameworky nějakou zkratku nebo pomocný dekorátor.

Šablony

Seskládávání HTML se běžně řeší přes šablony. Mako a Jinja2 jsou dva hlavní kandidáti pro většinu projektů, Django má pak své vlastní Templates.

Mám opravdu rád Mako. Velmi, velmi, velmi rád. Jděte a použijte ho. Používá pro svou syntax prostý Python a dělá to velice přirozeně. Lze dokonce psát celé úseky čistého Python kódu přímo v šablonách, ačkoliv tedy existence zrovna této vlastnosti by pro vás měla být spíše „kursem sebeovládání“ a měli byste ji využívat co nejméně. :-)

Jinja2 je celkem v pořádku. Má jednu nepříjemnou vadu: foo.bar se bere jako foo['bar'], pokud foo vypadá jako slovník. Já si myslím, že je to opravdu velice špatný nápad a v šablonovacích systémech se stejnou „vlastností“ mě potkala spousta drobných, nepříjemných problémů. (Navíc ta syntax {% %} je fakt nic moc, ale to už je vyloženě argumentace banalitami.) Kromě toho je však Jinja2 velice pěkná knihovna a určitě byste mohli vybrat hůř. Mnohem, mnohem hůř.

(Pozn. překl.: Ve výběru šablon se s autorem malinko rozcházím. Opravdu jsem si zamiloval Jinju2 – její syntax navazuje na šablony z Djanga a třeba Twig, šablonovací systém v PHP frameworku Symfony ji prakticky okopíroval. Je podobná i jiným běžně používaným – srovnejte s Latte. No a s onou popisovanou „vlastností“ jsem já osobně nikdy žádný problém neměl, ostatně je i v Djangu.)

Mako i Jinja2 jsou obě poměrně rychlé, automaticky se na pozadí kompilují do Python modulů, mají excelentní nástroje pro ladění (s šílenými hacky, které umožňují, aby uměly výjimky probublat hezky až z vašeho kódu v šabloně) a měly by být dost mocné na to, aby vám umožnily cokoliv si budete přát. Proleťte dokumentaci k oběma těmto knihovnám, jednu si vyberte a hotovo. Pokud si neumíte vybrat, použijte Mako. Flask tedy v základu používá Jinju2, ale je poměrně jednoduché ji vyměnit.

Existují samozřejmě i další projekty: Na třetím místě by se pravděpodobně umístila Genshi, ale ta je tak neskutečně komplikovaná, že už její homepage začíná vývojovým diagramem. Jak bylo už zmíněno, Django má své vlastní šablony, jež se velice úzkostlivě snaží oddělit logiku aplikace od HTML (podle mě ke své škodě). Bottle má rovněž své šablony, ale tak jednoduché, že by velice brzy způsobovaly akorát větší a větší potíže. Pyramid má kromě Mako ještě svůj vlastní systém, Chameleon. Ten ale pro cykly a další logiku používá atributy ve stylu HTML, což je tedy – fanoušci n:maker v Latte prominou – pěkně praštěné.

Možná se vám budou některé z těch dalších šablonovacích systémů líbit – já jsem je ale nepoužíval pro žádné netriviální věci. Ať už si ovšem vyberete cokoliv, nechť to proboha není Cheetah. NEPOUŽÍVEJTE knihovnu Cheetah. Je to zvrácená ohavnost. Už o ní nikdy nemluvme.

Logika v šablonách

Možná jste nikdy předtím šablony nepoužili. Pokud ano, určitě jste si někdy položili otázku, zda by měl nějaký složitý vykreslovací kód ležet spíše v šablonách, nebo raději v Pythonu.

Je to starý a hloupý argument, ale podám to takto: Stejně jako u mnoha jiných rozhodování o architektuře programů nejvíce záleží na tom, jak moc se budete později za výsledek nenávidět. Pokud můžete, vyhněte se komplexním konstrukcím v šablonách, ale pokud nemůžete, nesnažte se drbat levou nohou za pravým uchem jen pro samotnou čistotu řešení. Pamatujte, že vždy můžete napsat pár prostých Python funkcí v prostých Python modulech a importovat je. Silný šablonovací systém by mohl mít dokonce už v základu nějaké pěkné kreativní řešení pro to, co se snažíte docílit – zatímco přemýšlíte nad problémem, proleťte si raději znova dokumentaci.

Pokračování příště

Druhá a poslední část překladu vyjde příští týden.

Komentáře

Subscribe
Upozornit na
guest
50 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Ondřej Mirtes

> Jste otrávení z psaní webů v PHP?

Ne

> kdybyste se naučili Python, bude váš život krásnější, plnější, barevnější, prostě dokonalý od kořínků ke konečkům?

Ne

starenka

Radsi jezdit trabantem nez BMW? Ano
Myslis si, ze trabant je nejlepsi auto na svete, protoze s nim jezdi vsichni tvoji kamosi? Ano.

Aby to nebylo uplne k nicemu jako koment na kterej reaguju:
python-pip nemusi bejt vzdycky v nejaky rozumny versi, takze sje imo lepsi nainstalovat python-setuptools a pomoci easy_install pip nainstalovat nejnovejsi a lehce upgradovtelnou versi

Patrik Šíma

+1 ať si nikdo naivně nemyslí, že přechodem na jiný jazyk se nevyhne problémům. vždycky je zatím moře času a úsilí.

viktor.stiskala

Autor článku to bere s nadhledem a rozhodně to nemá znamenat, že přechodem na jiný jazyk všechno půjde samo. IMHO článek jenom popisuje zkušenost autora o kterou se chtěl podělit.

Já osobně jsem v PHP pracoval několik let a taky jsem nechápal proč někdo tak vychvaluje jiné jazyky (v té době nejvíce frčelo Ruby) a nadává na PHP. Žil jsem ve vlastním trochu omezeném světě a byl jsem do jisté míry spokojený se svým hlavním programovacím jazykem. K Pythonu jsem se dostal poprvé, když jsem v něm začal psát serverové skripty a přestal mi stačit Bash. O nějakou dobu později jsem se podíval na možnosti webových frameworků a začal se věnovat Pythonu naplno. V současné době je pro mě ale skoro utrpení se vracet ke starým PHP webům a snažit se tam něco upravovat. Chybí mi výrazové možnosti jazyka, 3rd party knihovny, jednotnost. To je ale jenom čistě moje zkušenost.

Stejně tak když někdo píše články o jiných jazycích (např. http://bit.ly/12rDxyo), tak si z toho snažím vzít to zajímavé. Tím chci jenom říct, že když mi jednou bude nějaký jazyk vyhovovat více, pravděpodobně na něj přejdu, ale nemám důvod pod článkem sdílet komentáře podobného typu.

Ondřej Mirtes

Můj komentář byl taky spíš vtip :) Ale ne úplně. Nevím, proč by se vývojář měl cítit blbě, když používá PHP, vyhovuje mu, zná všechny jeho zákoutí, vyzná se v ekosystému a slouží mu jako dobře nabroušená sekera. Nemám nic proti článku o Pythonu a přečtu si ho raději, než tisící nesmyslný test PHP frameworků, ale nevím, proč je potřeba se vymezovat proti PHP vývojářům.

Vím, proč používám PHP a za svoji volbou si stojím. Nemám problém vyzkoušet a začít používat jiný jazyk, koncepty jsou všude stejné (jen se jinak jmenují) a řeší ty samé problémy. Bakalářku jsem napsal v Pythonu a JavaScriptu, hraju si s vývojem na iOS v Objective-C, na serveru mi běží jeden skript v Perlu pro synchronizaci kalendářů, který jsem našel na GitHubu a upravil si ho k obrazu svému.

Ale z dlouhodobého hlediska tíhnu spíš ke staticky typovaným jazykům, protože v nich vidím dlouhodobou udržitelnost kódu. BMW mezi jazyky je pro mě Java :)

Martin Kuchař

Proti PHP se vymazují ti, kteří jej neumí. Ve webových aplikacích je pro mne PHP tím BMW..

Jan Bednařík

Proti PHP se vymezují ti, kteří zjistili, že věci se dají dělat jinak, pohodlněji a příjemněji. V PHP jsem programoval 10 let a troufám si tvrdit, že jsem ho uměl dobře. Za BMW jsem ho považoval taky, ale jen proto, že mi chyběl rozhled a zkušenosti s jinými jazyky a ekosystémy.

Ondřej Melkes

Můžu se zeptat, které nástroje jsi při vývoji v PHP používal? A které nástroje používáš nyní? Jazyk, framework, ide, pomocné nástroje?

vaclav.sir

Pro mě je teda PHP a jeho ekosystém spíš taková Multicar, než BMW. :-)

roman

neviem preco ste nespomenuli grok alebo plone (ked uz spominate django). Plone je pre zaciatocnika mozno trochu hard core, ale je dobre vediet ze je tu enterprise ready cms
R.

W.

Protože je to překlad(!) cizího článku.

Čelo

Za mě dobrý…. chci nášup :)

LH

Lze tedy nějak jednoduše na jednom serveru provozovat web v PHP a web v Pythonu?

Michal Wiglasz

Lze. PHP přes FastCGI, Python přes reverzní proxy: http://serverfault.com/questions/348584/python-app-server-web-server-co-existing

Ondřej Böhm

Jednoduše je relativní pojem, ale jde to třeba pomocí modwsgi. Pokud používáte Apache s worker MPM nemusíte ani restartovat server při změně kódu.

LH

Jde mi o (virtuální) server, kde už běží běžné PHP, klasický LAMP, a kde už tak běží některé PHP aplikace. S celkovým nastavením PHP by se už tak nemělo vůbec hýbat, nechci nic pokazit…

Ten mod_wsgi by asi měl dělat to, co chci. Nejsou s tím nějaké problémy, o kterých bych měl vědět? :-)

Ondra

V konfiguráku Apache stačí nastavit WSGIPythonPath na adresář s WSGI aplikací v Pythonu; zbytek konfiguráku se může věnovat třeba PHPčku…

LH

OK, díky, jsem rád, že to nějak půjde :).

rikiless

ja tiez nie, svet je s php frameworkami, composerom a dalsimi toolmi je dnes jednoduchsi. ale styl pisania clanku sa mi paci :) len tak dalej!

Petr Stanislav

Přednáška o web2py od tvůrce:

http://www.youtube.com/watch?v=LsLgZUGM3kg

diverman

Souhlasim s tim, ze python-cheetah je nejvetsi zlo. Vypada to, ze se na tom nekdo ucil python. Zkuste si precist .py soubor, ktery to vygeneruje. Takovej kod by nenapsal ani diletant. Bohuzel na strankach se uvadi, jak je „great and successfull“ a vetsina lidi tomu uveri.

Mirek

Proč se kdekdo naváží do Cheetahu? Byl by nějaký argument?
Že to generuje nehezký python kód jako argument neberu.
– Především je to interní kód, do kterého vůbec nemáš důvod koukat, možná by ses taky divil, jak jiné template jazyky renderují, kdybys do toho měl možnost vidět.
– Za druhé, je asi dost subjektivní, co je „nehezký“. Generované struktury by měly být jednoduché a stabilně fungovat pro jakoukoli povolenou zdrojovou syntaxi – to bych řekl Cheetah splňuje – nikdy jsem s ním žádné problémy neměl.
To, že jako mezikrok generuje ty .py soubory, může být docela přednost – nejspíš to pak poběží třeba pod Cythonem.
Taky vím, co mám odkud naimportováno, neobjevují se mi tam jména, o nichž těžko zjistit, odkud pocházejí (jako v Django templates).
A hlavně se skriptuje pythonem (jako (snad) Mako) a ne nějakým za každou cenu okleštěným ochuzeným jazykem. (chápu, že ve firmě, která má mraky python-backendistů a mraky kodérů, to ti programátoři můžou vidět jako nevýhodu).

Jakub Kulhan

Je houšť a větší kapky.

Hmm

Mna ale zaujima skor nieco ine. Aka je vyhoda Pythona oproti PHP? Co tym ziskam?

LH

Jako výhoda Pythonu čistě jako jazyka? Popíši, co se líbí mně:

— Python je více konzistentní a čistý v názvech funkcí a podobných věcech.
— Python je daleko stručnější, používá significant white spaces.
— List/set/dictionary comprehensions.
—V Pythonu se dobře pracuje s generátory, spousta nativních funkcí s nimi umí pracovat nebo je vytvářet.
— Tam kde PHP používá až tři různé cykly (for, foreach, while), tam v Pythonu většinou stačí jeden for cyklus.
— Python má tři základní struktur (seznam, množina a slovník), se kterými se dobře pracuje. V PHP se na vše používá array, což může být v některých případech zmatené.
— Vše je objekt.
— Já na Python přešel v době, kdy ještě PHP nemělo ani anonymní funkce, ale to už dnes odpadá. Ač nevím, jak moc už jsou v PHP rozšířené.

Martin Kuchař

Tenhle příspěvek se mi moc líbí. Myslím, že ukazuje, že není lepšího a horšího jazyka, nýbrž jen jiných potřeb a pohledů programátora. Já dělám v PHP od verze 2. Prošel jsem kurzem Pythonu u MIT a vrátil se k PHP. Zatímco s body 1 a 2 souhlasím, právě body 3-7 se mi na Pythonu nelíbí a proto MNĚ osobně připadá PHP mnohem přehlednější a přímočařejší.

Michal Wiglasz

Mohl bys prosím více rozvést, v čem se ti ty body nelíbí?

Martin Kuchař

+1

Foo

Fajn clanek. Skoda jen, ze jej mistni grudljungens asi moc neoceni :-)

Jaroslav Kubíček

Nevím proč by tomu tak mělo být, já normálně pracují s Nette, ale nebrání mi to v tom, abych zkoušel ve volném čase i Python…

Jaroslav Kubíček

díky za tento článek! Jak je to s Apachem, když to pojedu přes WGSI, jak jednoduše reloadnu aplikaci, když dojde ke změně souboru?

Josef Skladanka

Zalezi jestli to chces delat automagicky, nebo ne. Ne-magicky staci neco jako service httpd reload (da se napriklad nastavit jako hook na push do git repa na serveru), jinak je tu bud WSGIScriptReloading (reaguje na zmenu .wsgi konfiguraku), pripadne sledovani souboru timhle zpusobem: http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode

Honza Kral

Diky za clanek Honzo!

Jen bych pridal radu kterou davam lidem kteri chteji zacit s Pythonem pro web: pouzijte Django.

Ne proto, ze by to byla nutne nejlepsi volba na kazdy webovy projekt, ale proto, ze udela spousta rozhodnuti za vas a ty rozhodnuti budou „dost dobra“ (good enough) pro takrka libovolny webovy projekt. Po prvnim (klidne jen testovacim) projektu s Djangem pak budete mit lepsi predstavu o tom co je pro vas u frameworku dulezite a budete si moci vybrat zda zustat u Djanga nebo se poohlednout po necem flexibilnejsim (flask, bottle, pyramid, …).

Zkratka vam umozni rychle zacit a neco tvorit – diky tomu ze ma vse potrebne jiz v sobe (orm, forms, http, sessions, auth, …) i diky velkemu mnozstvi materialu pro vsechny vykonostni kategorie.

Full disclosure: Jsem core vyvojar Djanga a django pouzivam na vsechny sve webove projekty – nejsem nezaujaty.

radek.zilka.3

Když chci s něžím začínat, tak to nejraději využiju na nějaký malý web/aplikaci a hledám do začátku funkční free hosting, kde si můžu svoje věci veřejně vyzkoušet. Jak jsou na tom hostingy pro Python?

Huge

Doporučím třeba pythonanywhere.com. Mají výborný přístup.

J.

Kormidlujete tu od frameworku ku frameworku. Od jedneho super duper sexy dynamickeho jazyku k druhemu. Naucte sa dobre, .Net. Javu a spravite vsetko . Jaaaaj nie… to nie je nic pre vas, to nie je proste sexy. To je len pre enterprise lamy co si len pockaju na pravidelnu vyplatnu pasku. :-)

Martin Putniorz

> Naucte sa dobre, .Net. Javu a spravite vsetko
Na všechny šrouby taky není jeden šroubovák.
> To je len pre enterprise lamy co si len pockaju na pravidelnu vyplatnu pasku.
Proč je urážíte? Já takové lidi respektuji – baví je práce, která mě nebaví.

Každý by si měl najít nástroj, který mu vyhovuje. A aby ho našel, musí si ho vyzkoušet. I pokud ho potom nebude používat, může mu to přinést zkušenosti, jaké by jinde nezískal.

sveta.margetova

Bolo zaujimave citat vasu diskusiu. Normalne mi to dalo aj zabrat. No my teraz v praci prechadzame zo Zend Frameworku na Django a ideme prepisat celu aplikaciu, neviete nam poradit ako na to? Ako s prepisom zacat, ci zacat navrhom od znovu a databazou? mne osobne sa python ovela viac paci a ovela viac mi vyhovuje ako PHP . Tesim sa na pokracovanie clanku

jbub

nedavno bola o tom prednaska na PyCone, chlapik stravil posledne 3 roky prechodom z PHP na Django, myslim ze su tam celkom zaujimave poznatky: http://pyvideo.org/video/2233/transitioning-from-php-to-django-on-the-sly

JackHat

Koukám na werkzeug. Nějaký komentář nebo zařazení do kontextu tohohle (skvělého) článku?

Kaacz

.. kdybyste se naučili Python, bude váš život krásnější, plnější, barevnější, prostě dokonalý od kořínků ke konečkům? ..
Zkusil jsem jednou .. A UŽ NIKDY VÍCE! :)
LOL, asi bych měl začít hulit… jinak tohle nedám…
Na větší projekt je Python tragédie.. a na ladění taky .. už chápu, proč MythTV nefunguje pořádně ..
1) zkuste zakomentovat podmínku => musíte posunout indent o jeden doleva .. po zrušení komentu opět indent vpravo .. VOSER!
2) bez závorek se hůře hledá co k sobě patří .. a i inteligentní editor je bez závorek dost v loji. V Pythonu mi moc nepomáhá .. protože sám neví která bije .. prostě tregédie. :)
Resume: všichni víme že hadí jazyk je špatný a Zmijozel je špatná kolej.. :)
PS: jako jazyk pro výuku – OK, ale tam by měl zůstat zavřen .. :)

Kaacz

Pro ujasnění: neznám PHP. Nedělám WEB podivnosti. Potřebuji skriptovací jazyk, na věci, na které mi nestačí bash/unix možnosti. Zatím jsem se vždy vrátil k Perlu. Jeho HASH pole jsou pro mne BMW. Programuje se to fakt jednoduše, neřeším blbosti jako indexy a hledání. Načtu do (hash arrays) strukturovaného stromu podivné konfigurace (Cisco router-switche, ACE balancery, Juniper firewall) a pak z nich vytvořím HTML přehledné a čitelné pro člověka. Obzvláště ten balancer je lahůdka – výstup v logické struktuře každého virtuálu. :)
A vo vo vo tom to je… :)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.