Pythonní arzenál pro web, proč není hosting ?

30.1.2007 09:11 | Přečteno: 1720× | Python

Nedávno jsem se koukal, včem bych tak mohl spáchat CMS pro blog a i přes ne zrovna velkou podporu Pythonu a už vůbec žádnou podporu jeho frameworků jsem se rozhodl pro Python, mám ho rád a nechci se trhnout k jinému jazyku ...

U frameworku byla jasná volba. CherryPy.
Django jsem nechtěl, dělá toho za mě až moc, CP mi nabízí jen to nejnutnější, systém linkování, práci s GET/POST, atd.

Další vybírání se týkalo templatovacího systému a práce s databází. Tady se divím jedné věci. Projekty jako třeba KID a SQLAlchemy mi připadají jako hodně šikovné věci. A tak mi není jasná tak malá popularita mezi lidmi v ČR. Nebo se o tom jenom tak nepíše jako třeba o snad všude podporovaném PHP ?
Bavil jsem se o tom s Danielem Kvasničkou a podle něj to bude právě absencí hostinu pro weby postavené na Pythonu + frameworcích. To bude nejspíš pravda.
Škoda, protože vývoj pomocí těchto nástrojů je fakt paráda, i přes počáteční nezdary kdy mi Daniel docela dost pomohl. Za to mu dík.
S trochou štěstí nějaký člověk tuto díru na trhu vyplní, do té doby budu mít svůj CMS jenom na lokále, každopádně nějaké plky na téma Python a web ode mě čekejte, nadšení je veliké a chci se podělit o pár fíglů ..

       

Komentáře

[LuděkS]

já bych se s djangem rád víc seznámil, takže budu rád sledovat jak se věci ohledně hostingu a pythonu budou vyvíjet. Držím palce

[Martin Stiborský]

Psal jsem na klenot.cz a tam o nasazení uvažují, ale bylo mi řečeno, že se zatím testuje bezpečnost, takže jednou ... možná .. doufejme

[Jiří P.]

Ja jsem priznivcem TurboGears a taky cekam na cesky hosting... (zatim bohuzel marne).

Kdyz uz si clovek jednou zvykne na komfort, ktery mu tyhle frameworky prinasi a pak musi bastlit nevo v PHP, protoze hosting proste neni, tak by jeden zaplakal...

[Michal Kubeček]

Tohle znám, často taky narážím na všudypřítomnost MySQL a ignorování ostatních databází. Naštěstí jsem nikdy nebyl nucen využívat služeb webhostingu, takže mne to zase až tak nepálí.

[s0]

mno, ono třeba s tím sqlachemy mohou být docela výkonnostní problémy. Prostě se může stát, že selekty do db nebudou dobré. Jistě, v případě pár záznamů to nevadí, ale jakýkoukoli složitější logiku se do takových frameworků (ať už jsou v jakémkoli jazyce) bojím nacpat. A bohužel skoro každý den vidím, že se java/.net vývojáři do nich pouštějí a a rozbíjejí si své rypáky.

Zkrátka a prostě selekty patří na DB, ne do klienta.

Pár člověkodní si pohrávám s djangem a je to opět to samé. Pekelně rychlý vývoj kódu, DB to za mne udělá, ale tablespace stejně musím poklízet a řekněme 10% dotazů stejně napíšu lépe, než jak je připraví django db layer. A to nemluvím o manuálně vytvářených indexech "aby se to vůbec trochu hejbalo."

P.S.: komentáře vztahujme ke GB až TB dat.

[Daniel Kvasnička ml.]

Pár člověkodní si pohrávám s djangem a je to opět to samé. Pekelně rychlý vývoj kódu, DB to za mne udělá, ale tablespace stejně musím poklízet a řekněme 10% dotazů stejně napíšu lépe, než jak je připraví django db layer. A to nemluvím o manuálně vytvářených indexech "aby se to vůbec trochu hejbalo."

Nejvetsi problem s Djangem je prave to, co je v jistych pripadech naopak nejvetsi vyhodou a to je jeho specializace. Jeho vyvojari jsou novinari a vyvijeli ho presne pro sve potreby (publikace clanku, document-oriented veci), ale jak chce clovek neco vic nebo neco jinak, pekne se zapoti. Proto mam na urcitou oblast veci mnohem radsi TurboGears, ktery mi sice negeneruje CRUD, ale napsat to v nem trva kratsi dobu nez hackovat generovany CRUD z Djanga.

Jako dalsi vyhodu TG oproti Djangu vnimam taky Kid.

Jinak ke GB az TB dat se to proste a jednoduse vztahovat neda, protoze (IMHO) vyvojari techto frameworku pri jejich designu nikdy o GB a TB dat nepremysleli.

[Daniel Kvasnička ml.]

Myslim ze jde o to narazit na flexibilni a ochotny hosting. Mod_python uz par hostingu ma a podle me stoji za to se jich optat, jestli ti treba ten Kid nenainstaluji. A nebo pouzit vestaveny templating mod_pythonu -- porad o tridu lepsi nez PHP.

S temi frameworky si proste budem muset pockat. Musime hulakat, protoze kdyz nebude poptavka, nebude hosting.

[Botanicus2]

Taky si prihreju polivcicku --- a co Ruby && RoR? Taky nic moc ... tusim, ze na obsidianu to podporujou (slysel jsem, neoveroval), ale obecne je to des a bida. Pritom zajem by urcite byl...

Botanicus

[Daniel Kvasnička ml.]

Ja si myslim, ze kolem RoR je trochu vic povyku nez kolem pythonskych nastroju, takze railsisti si na sve mozna prijdou drive... Otazka ale je, zda vubec je tak uplne nutne mit CESKY hosting (a to plati i pro Python). Na RoR wiki se daji najit celkem prijatelne evropske hostingy...

[Botanicus2]

Chyba v matrixu...samozrejme mas pravdu...jen nechapu, ze mi to nedocvaklo :) Jo, evropske, to je ono :)

[Pavel Siska]

Ja myslim, ze tomu rozsireni mezi hostery brani prave nemoznost zabezpeceni. Stacilo by implementovat neco jako open_basedir, disable_functions a nebyl by problem to pustit.

[Daniel Kvasnička ml.]

Moznosti zabezpeceni urcite jsou, jinak by se temito technologiemi masivne nezabyval treba britsky WebFaction...

[azurIt]

praveze nie su

[Daniel Kvasnička ml.]

Rozvedte to...

[Pavel Siska]

Samozrejme kazdy web muze dostat chroot atd, ale bavme se rozumnych formach zabezpeceni, ktere jdou jednoduse pouzit a hostingy je mohou nasadit. Tady vidim mezeru.

[Dan Ohnesorg]

Nekdy za 14 dni budu davat na serverovnu masinu, ktera se bude strasne nudit.

Bude tam mod_python pro nase vyvojove veci, kdyz nekdo duveryhodny bude mit nejaky inteligentni projekt neni s tim problem. Nemuzu garantovat extra spolehlivost, ale starat se o ni bude 6 lidi, tak by snad nemely byt vypadky delsi nez par hodin, pokud vubec nastanou.

Zrejme tam pobezi apache v chrootu na ruznych portech a budou pristupne pres mod_proxy, ktera bude prichozi provoz rozhazovat podle virtualu na jednotlive porty. Mozna se nasadi i xen, bude to takovy overovaci provoz smerujici k nejakemu ostremu nasazeni asi za rok. Masina s 3GHz P4 a 1G pameti by si s tim mohla poradit.