Re: [python] Volba web-frameworku (a pár menších dotazů)
Bottle je podle me spis na skolni priklady, ale znam startupy, ktery na tom delaji produkcni sw :) Do Flasku si na formulare vem https://flask-wtf.readthedocs.org/en/latest/ Honza 2015-02-11 14:35 GMT+01:00 starenka . staren...@gmail.com: Btw: pokud mas na vyber jen dve (nebo relativne malo) moznosti je podle me lepsi misto selectboxu (dropdownu), pouzit radia... --- In Perl you shoot yourself in the foot, but nobody can understand how you did it. Six months later, neither can you. | print 'aknerats'[::-1] 2015-02-11 14:34 GMT+01:00 starenka . staren...@gmail.com: Ahoj, Flask/bottle je podle me uplne dostacujici. V kazdym pripade bych asi trochu osetril vstupy (napr pokud mi to dovoli sipkama kliknout rok -1, tak se ti to zhrouti) Pro tip: tlacitko smazat formular je podle me naprosto k nicemu --- In Perl you shoot yourself in the foot, but nobody can understand how you did it. Six months later, neither can you. | print 'aknerats'[::-1] 2015-02-11 14:04 GMT+01:00 Marcus Scalpere marcus.scalp...@gmail.com: Zdravím, řeším dilema ohledně web-frameworku. Bohužel nemám zkušenosti s webdesignem, první pokus dopadl takto http://edelstadt.pythonanywhere.com/ (vůbec netuším, jestli je v pořádku mít kupu formulářů na jedné stránce), ale dostal jsem pár dalších nápadů (a nejspíš mě napadnou další), takže bych to potřeboval buď rozšířit nebo vytvořit něco úplně nového. Co zvolit? Osobně jsem zúžil výbět na Flask, Bootle a Pyramid. Uvedená verze je ve Flasku, ale občas jsem měl problém poprat se právě s formuláři. Navíc bych chtěl generovat takový event calendar, který bude (asi?) sosat data ze dvou různých zdrojů (události, které se opakují každý rok ve stejný den a události, které jsou v různé dny, taky by se hodil nějaký návrh), takže netuším, jestli to ještě spadá do micro-blogu nebo už je to o level víc. A spíš průzkumná otázka - je vůbec šance nějaknechci říci přímo vydělat, možná monetizovat takový nápad? ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] Seznamy
Já bych snad jen dodal, že obrovská síla Pythonu je v tom, že je
multiparadigmatický, a umožňuje volit objektový, funkcionánlní, či
procedurální přístup pro řešení konkrétních problémů. A myslím si že
dobrého programátora nedělá to, že dokáže všechno naprogramovat v jednom
oblíbeném paradigmatu, ale že dokáže volit to nejelegantnější řešení pro
daný problém.
Není problém pokud nevím, jak něco vyřešit. Problém je, když znám jen jedno
řešení.
Honza
2015-02-11 10:08 GMT+01:00 Vladimir Macek ma...@sandbox.cz:
On 10.2.2015 20:50, Honza Král wrote:
2015-02-10 20:36 GMT+01:00 Radek Holý radekholypub...@gmail.com:
V Pythonu dělám skoro 9 let a pořád platí, že kdykoliv někde
narazím na reduce, map apod. tak mě to vždy zdrží a chvíli mi
trvá, než pochopím o co jde. List comprehensions se mi čtou
snadněji - přirozeněji. Nehledě na to, že ty funkcionální
záležitosti jsou skoro vždy spojené s deklarací jinak zbytečných
funkcí se složitým významem, nebo ještě komplikovanějšími lambda
funkcemi. Každopádně je to prostě otázku vkusu/zvyku... Jedním z
problémů může pro mě být ta prefixová notace. Vypadá to jako Lisp
:-)
Doufám, že se shodneme, že to je věc osobních preferencí a nebudeme si to
navzájem vyčítat. :-) Zajisté můžu považovat za elegantnější vytáhnout
filtrační nebo transformační logiku do extra funkce s komentáři a pak jí
předhodit do filter/map než to patlat do třířádkového C-G. Podotýkám pro
jistotu znovu, že používám jak filter/map + zřídka reduce, tak C-G, vždy
podle svého citu pro vhodnost. Snažím se dodržovat Zen.
Kdykoli píšu \, trošku uvnitř umřu.
Vidim to uplne stejne, proto jsem byl prekvapen kdyz tady slysim
zastance filter/map/... Ja osobne se k nim skutecne uchyluji jen
obcas kvuli vykonu a v situaci kdy je naprosto jasne, co to bude
delat.
To poslední negrokuju. :-) Jasné je snad v Pythonu vše, proto ho máme rádi,
ne? :-)
Ještě mě zarazilo to stáhneme 10 URL. S tím mám vždy osobní
problém. Jakmile někdo volá map, aniž by ho zajímala návratová
hodnota volané funkce, považuji to za chybu. Nehledě na to, že v
Pythonu 3 map vrací iterátor, takže se kvůli tomu ještě typicky
map obaluje do list... V těchto případech vždy preferuji
klasický for cyklus. Ale opět je to jen můj názor.
Dovoluji si i zde spíše nesouhlasit, zejména se slovem typicky.
Přetypování tohoto typu snad používáme až tehdy, kdy je to nutné, ne?
Pokud někde dostanu iterátor, je hromada případů, kdy se elegantně a
efektivně použije přímo.
Naprosty souhlas, parkrat jsem videl volani map ci list
comprehension bez zajmu o vysledek a take s tim mam problem - je to
plytvani (zbytecne se alokuje list) a je to hure citelne.
Nedochází mi, kde jste vzali, že spojuju příklad se stažením 10 URL s
map(), psal jsem zrovna, že jsem na tom příkladu ilustroval C-G. Ale i na
map() se to dá použít
map(urllib.urlopen, ('http://www.seznam.cz', 'http://google.com',
'http://ibm.com'))
Též nerozumím tomu, jak jste vyvodili, že se jak v tomto případu, tak v tom
mnou prve zmíněném s C-G nezajímám o návratovou hodnotu.
Jednak jsem to zmiňoval jako rychlou ukázku C-G jakožto konstruktu pro
studenty (kde se navc netvoří profesionální kód), za druhé mohu dostat
všechny potřebné informace vč. stavových a za třetí... kam se vám poděl
EAFP (https://docs.python.org/2/glossary.html)?
Mimochodem v python3 uz reduce ani neni builtin (byl presunuty do
functools) a i Guido to vidi obdobne:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
S tím souhlasím, nic proti. Sám jsem psal, že ji používám zřídka.
Děkuji za diskusi, štvete mě jen malinko. :-)
Vl.
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python
Visit: http://www.py.cz
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python
Visit: http://www.py.cz
Re: [python] Seznamy
On 11.2.2015 10:29, Petr Viktorin wrote: Kdykoli píšu \, trošku uvnitř umřu. C/G ale zpětná lomítka nepotřebují, protože jsou vždycky v závorkách. To zajisté vím. Nebylo by prosím možné vnímat poněkud velkoryseji a nedoslovně? :-) Šlo o obecné zvolání, že preferuju jednořádkové konstrukty, složitější věci oddělené do funkcí a metod, dráždí mě skoro každé odsazení, takže se vyhýbám i try: ... except: a pohodový flow se snažím zajistit jinak... Není to zde ale důležité, osobní věc. Vl. ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] Seznamy
Dne pátek 6. února 2015 20:10:15 UTC+1 Marcus Scalpere napsal(a): Pěkný večer vinšuji, mám několik seznamů a potřebuji zjistit, které jsou a nejsou prázdné (to bych ještě dal) a pokud některé prázdne nejsou, tak je projít a pokud jsou některé hodnoty ve VŠECH, tak je uložit. Něco jako: list_a = [] list_b = [x, y, z] list_c = [x, y] . . . list_vysledny = [x, y] Snad jsem se vyjádřil jasně a srozumitelně. Děkuji mnohokráte Mnohokráte děkuji pánové, jsem netušil, že se z toho stane takhle rozsáhlá diskuze (použil jsem hned první řešení, tudíž se velice omlouvám ostatním, nevyužitým), nechci vypadat nějak nevděčně, snažím se pochopit vše, ale použít mohu jen jednu. Bohužel, nepředpokládám, že by moje tvorba byla jakkoli více studovaná a používá, tak si ani nemusím zas až tak dělat starosti s elegantností kodu. Vlastně bych už mohl napsat něco s názvem Postřehy začátečníka v pythonu s psaním nezačátečnický app... ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] Seznamy
On 10.2.2015 20:50, Honza Král wrote:
2015-02-10 20:36 GMT+01:00 Radek Holý radekholypub...@gmail.com:
V Pythonu dělám skoro 9 let a pořád platí, že kdykoliv někde
narazím na reduce, map apod. tak mě to vždy zdrží a chvíli mi
trvá, než pochopím o co jde. List comprehensions se mi čtou
snadněji - přirozeněji. Nehledě na to, že ty funkcionální
záležitosti jsou skoro vždy spojené s deklarací jinak zbytečných
funkcí se složitým významem, nebo ještě komplikovanějšími lambda
funkcemi. Každopádně je to prostě otázku vkusu/zvyku... Jedním z
problémů může pro mě být ta prefixová notace. Vypadá to jako Lisp
:-)
Doufám, že se shodneme, že to je věc osobních preferencí a nebudeme si to
navzájem vyčítat. :-) Zajisté můžu považovat za elegantnější vytáhnout
filtrační nebo transformační logiku do extra funkce s komentáři a pak jí
předhodit do filter/map než to patlat do třířádkového C-G. Podotýkám pro
jistotu znovu, že používám jak filter/map + zřídka reduce, tak C-G, vždy
podle svého citu pro vhodnost. Snažím se dodržovat Zen.
Kdykoli píšu \, trošku uvnitř umřu.
Vidim to uplne stejne, proto jsem byl prekvapen kdyz tady slysim
zastance filter/map/... Ja osobne se k nim skutecne uchyluji jen
obcas kvuli vykonu a v situaci kdy je naprosto jasne, co to bude
delat.
To poslední negrokuju. :-) Jasné je snad v Pythonu vše, proto ho máme rádi,
ne? :-)
Ještě mě zarazilo to stáhneme 10 URL. S tím mám vždy osobní
problém. Jakmile někdo volá map, aniž by ho zajímala návratová
hodnota volané funkce, považuji to za chybu. Nehledě na to, že v
Pythonu 3 map vrací iterátor, takže se kvůli tomu ještě typicky
map obaluje do list... V těchto případech vždy preferuji
klasický for cyklus. Ale opět je to jen můj názor.
Dovoluji si i zde spíše nesouhlasit, zejména se slovem typicky.
Přetypování tohoto typu snad používáme až tehdy, kdy je to nutné, ne?
Pokud někde dostanu iterátor, je hromada případů, kdy se elegantně a
efektivně použije přímo.
Naprosty souhlas, parkrat jsem videl volani map ci list
comprehension bez zajmu o vysledek a take s tim mam problem - je to
plytvani (zbytecne se alokuje list) a je to hure citelne.
Nedochází mi, kde jste vzali, že spojuju příklad se stažením 10 URL s
map(), psal jsem zrovna, že jsem na tom příkladu ilustroval C-G. Ale i na
map() se to dá použít
map(urllib.urlopen, ('http://www.seznam.cz', 'http://google.com',
'http://ibm.com'))
Též nerozumím tomu, jak jste vyvodili, že se jak v tomto případu, tak v tom
mnou prve zmíněném s C-G nezajímám o návratovou hodnotu.
Jednak jsem to zmiňoval jako rychlou ukázku C-G jakožto konstruktu pro
studenty (kde se navc netvoří profesionální kód), za druhé mohu dostat
všechny potřebné informace vč. stavových a za třetí... kam se vám poděl
EAFP (https://docs.python.org/2/glossary.html)?
Mimochodem v python3 uz reduce ani neni builtin (byl presunuty do
functools) a i Guido to vidi obdobne:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
S tím souhlasím, nic proti. Sám jsem psal, že ji používám zřídka.
Děkuji za diskusi, štvete mě jen malinko. :-)
Vl.
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python
Visit: http://www.py.cz
Re: [python] Seznamy
2015-02-11 10:08 GMT+01:00 Vladimir Macek ma...@sandbox.cz: On 10.2.2015 20:50, Honza Král wrote: 2015-02-10 20:36 GMT+01:00 Radek Holý radekholypub...@gmail.com: V Pythonu dělám skoro 9 let a pořád platí, že kdykoliv někde narazím na reduce, map apod. tak mě to vždy zdrží a chvíli mi trvá, než pochopím o co jde. List comprehensions se mi čtou snadněji - přirozeněji. Nehledě na to, že ty funkcionální záležitosti jsou skoro vždy spojené s deklarací jinak zbytečných funkcí se složitým významem, nebo ještě komplikovanějšími lambda funkcemi. Každopádně je to prostě otázku vkusu/zvyku... Jedním z problémů může pro mě být ta prefixová notace. Vypadá to jako Lisp :-) Doufám, že se shodneme, že to je věc osobních preferencí a nebudeme si to navzájem vyčítat. :-) Zajisté můžu považovat za elegantnější vytáhnout filtrační nebo transformační logiku do extra funkce s komentáři a pak jí předhodit do filter/map než to patlat do třířádkového C-G. Podotýkám pro jistotu znovu, že používám jak filter/map + zřídka reduce, tak C-G, vždy podle svého citu pro vhodnost. Snažím se dodržovat Zen. Kdykoli píšu \, trošku uvnitř umřu. C/G ale zpětná lomítka nepotřebují, protože jsou vždycky v závorkách. A i ty třířádkové můžou být stručné a přehledné – někdy přehlednější než to všechno cpát na jeden řádek. names = ','.join(it.name for it in items if it.enabled) Vytáhnutí filtrační/transformační logiky do vlastní funkce je samozřejmě možné i tady. ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
[python] Volba web-frameworku (a pár menších dotazů)
Zdravím, řeším dilema ohledně web-frameworku. Bohužel nemám zkušenosti s webdesignem, první pokus dopadl takto http://edelstadt.pythonanywhere.com/ (vůbec netuším, jestli je v pořádku mít kupu formulářů na jedné stránce), ale dostal jsem pár dalších nápadů (a nejspíš mě napadnou další), takže bych to potřeboval buď rozšířit nebo vytvořit něco úplně nového. Co zvolit? Osobně jsem zúžil výbět na Flask, Bootle a Pyramid. Uvedená verze je ve Flasku, ale občas jsem měl problém poprat se právě s formuláři. Navíc bych chtěl generovat takový event calendar, který bude (asi?) sosat data ze dvou různých zdrojů (události, které se opakují každý rok ve stejný den a události, které jsou v různé dny, taky by se hodil nějaký návrh), takže netuším, jestli to ještě spadá do micro-blogu nebo už je to o level víc. A spíš průzkumná otázka - je vůbec šance nějaknechci říci přímo vydělat, možná monetizovat takový nápad? ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] Volba web-frameworku (a pár menších dotazů)
Ahoj, Flask/bottle je podle me uplne dostacujici. V kazdym pripade bych asi trochu osetril vstupy (napr pokud mi to dovoli sipkama kliknout rok -1, tak se ti to zhrouti) Pro tip: tlacitko smazat formular je podle me naprosto k nicemu --- In Perl you shoot yourself in the foot, but nobody can understand how you did it. Six months later, neither can you. | print 'aknerats'[::-1] 2015-02-11 14:04 GMT+01:00 Marcus Scalpere marcus.scalp...@gmail.com: Zdravím, řeším dilema ohledně web-frameworku. Bohužel nemám zkušenosti s webdesignem, první pokus dopadl takto http://edelstadt.pythonanywhere.com/ (vůbec netuším, jestli je v pořádku mít kupu formulářů na jedné stránce), ale dostal jsem pár dalších nápadů (a nejspíš mě napadnou další), takže bych to potřeboval buď rozšířit nebo vytvořit něco úplně nového. Co zvolit? Osobně jsem zúžil výbět na Flask, Bootle a Pyramid. Uvedená verze je ve Flasku, ale občas jsem měl problém poprat se právě s formuláři. Navíc bych chtěl generovat takový event calendar, který bude (asi?) sosat data ze dvou různých zdrojů (události, které se opakují každý rok ve stejný den a události, které jsou v různé dny, taky by se hodil nějaký návrh), takže netuším, jestli to ještě spadá do micro-blogu nebo už je to o level víc. A spíš průzkumná otázka - je vůbec šance nějaknechci říci přímo vydělat, možná monetizovat takový nápad? ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
Re: [python] Volba web-frameworku (a pár menších dotazů)
Btw: pokud mas na vyber jen dve (nebo relativne malo) moznosti je podle me lepsi misto selectboxu (dropdownu), pouzit radia... --- In Perl you shoot yourself in the foot, but nobody can understand how you did it. Six months later, neither can you. | print 'aknerats'[::-1] 2015-02-11 14:34 GMT+01:00 starenka . staren...@gmail.com: Ahoj, Flask/bottle je podle me uplne dostacujici. V kazdym pripade bych asi trochu osetril vstupy (napr pokud mi to dovoli sipkama kliknout rok -1, tak se ti to zhrouti) Pro tip: tlacitko smazat formular je podle me naprosto k nicemu --- In Perl you shoot yourself in the foot, but nobody can understand how you did it. Six months later, neither can you. | print 'aknerats'[::-1] 2015-02-11 14:04 GMT+01:00 Marcus Scalpere marcus.scalp...@gmail.com: Zdravím, řeším dilema ohledně web-frameworku. Bohužel nemám zkušenosti s webdesignem, první pokus dopadl takto http://edelstadt.pythonanywhere.com/ (vůbec netuším, jestli je v pořádku mít kupu formulářů na jedné stránce), ale dostal jsem pár dalších nápadů (a nejspíš mě napadnou další), takže bych to potřeboval buď rozšířit nebo vytvořit něco úplně nového. Co zvolit? Osobně jsem zúžil výbět na Flask, Bootle a Pyramid. Uvedená verze je ve Flasku, ale občas jsem měl problém poprat se právě s formuláři. Navíc bych chtěl generovat takový event calendar, který bude (asi?) sosat data ze dvou různých zdrojů (události, které se opakují každý rok ve stejný den a události, které jsou v různé dny, taky by se hodil nějaký návrh), takže netuším, jestli to ještě spadá do micro-blogu nebo už je to o level víc. A spíš průzkumná otázka - je vůbec šance nějaknechci říci přímo vydělat, možná monetizovat takový nápad? ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz ___ Python mailing list python@py.cz http://www.py.cz/mailman/listinfo/python Visit: http://www.py.cz
