Vezmu to poporade: > Otázka. Obětovali byste některý z dynamických rysů pythonování výměnou třeba > za (hypotetické) zisky, jako aby mainstreamový interpret
> * se všem zrychlil v průměru o 15% či o 20%? rozhodne ne, jak uz tu napsalo spoustu lidi jsou lepsi zpusoby jak zrychlit kod v pythonu a vetsina pythoniho kodu neni zavisla na rychlosti jazyka > * se dal kompilovat do efektivního nativního kódu? opet argument ciste o rychlosti a odpoved je jeste rozhodnejsi ne protoze nativni kod ma limitace ktere jsou jeste silnejsi nez by bylo nutne obetovat pro zrychleni > * umožňoval výrazně lepší podporu automatické statické kontroly kódu? za me opet ne - preferuji tu volnost a s ni spojenou rychlost vyvoje a expresivitu kodu ktery minimalizuje nutnost automaticke staticke kontroly kodu. V situacich, kde je to zadouci je to v pythonu mozne i v soucasnosti externe skrze mypy a anotace a nevidim jediny duvod to zabudovavat do pythonu direktivne misto anotaci. > * ... tohle je pro me ta nejzajimavejsi otazka - hrozne casto se lide bouri proti prilisne dynamicnosti nekterych jazyku a chteji to omezovat nebo argumentuji, ze bez toho "to nejde", neni to vhodne pro velke projekty a nebo to nikdy nebude dost rychle. A core team pythonu to vesele ignoruje, dal zrychluje python a dela podporu tem obrovskym projektum ktere v pythonu vesele existuji. Tak nejak mi tam chybi ten dramaticky duvod k temto diskuzim. je to vetsinou jen filozofovani u piva nad tim jak by nektere veci byly jednodussi kdybychom meli staticke typovani nebo slozene zavorky ktere zcela ignoruji celkovy design toho jazyka a ekosystemu. Prijde mi to jako debata na tema jak by nakladaky byly o mnoho rychlejsi a uspornejsi kdyby nemusely vozit ten otravny naklad. > Nebo si to mám jednoznačně vyložit jako "svobodnou dynamičnost jazyka > neomezovat, protože zmíněný hypotetický zisky ve skutečnosti většina > nevyužije nebo je možné jich dosáhnout jinak"? Nebo proste tak, ze ten jazyk tak, jak je navrzen, nedava smysl ve sve staticke verzi a nelze polemizovat o jednotlivych featurach jazyka bez kontextu toho k cemu byl zamyslen, jak se pouziva a jak vypada prace s nim. > Víte, mě se vždy líbila myšlenka RISC v obklopení bloatem CISC. Přemýšlím, > jestli Python trochu nezakopává o svojí nespoutanost ve chvíli, kdy záměrem > je psát v něm opravdu velký => konzistentní a stabilní systém. Vím, že se v něm (úspěšně) píšou. Ted je rada na me abych nerozumel - pisou se v nem velke uspesne projekty a presto lide stale tvrdi, ze by se lepe psaly, kdyby byl staticky typovany. Proc? Na zaklade ceho tohle rikas? Empiricky je jasne videt, ze to prekazka neni tak proc se tohle vytahuje stale dokola a proc je to brane jako OK navrhnout nazor ktery je v rozporu s realitou a nepodlozit ho argumenty? > Nemusíte mě nutně brát doslova, uvažuju. Vim, ze to pises z pozice, ze o tom premyslis, ale i tam je potreba se ptat proc - vsichni zname dost velkych projektu v pythonu a mnoho neuspesnych projektu ve statickych jazycich. Evidentne to neni podminka ani nutna, ani dostacujici. Honza Král E-Mail: honza.k...@gmail.com Phone: +420 606 678585 2017-01-03 14:42 GMT+01:00 Pavel Řihošek <pavel.riho...@outlook.com>: > Něco na způsob statické kontroly kódu už v pythonu existuje. > Je to mypy, ve kterém se osobně angažuje Guido. > http://mypy-lang.org/ > http://www.elfsternberg.com/2016/12/04/write-python-mypy/ > > V Pythonu 3 koneckonců objevily typové anotace, které toto umožňují > elegantněji než Python 2.7. To že o nich lidé > buď neví, nebo jim nerozumí nebo bůhví proč je vlastně nepoužívají, je věc > jiná. Kontrolu kódu umí i PyCharm. > Dále, pokud si přečteš novinky v 3.6, pak se tam cosi o vylepšené podpoře > JIT kompilátorů objevuje. > > http://www.infoworld.com/article/3149782/application-development/python-36-is-packed-with-goodness.html > > Mimochodem, Python jako takový je specifikace jazyka, nikoliv jeho > implementace. CPython, který ty myslíš, je referenční implementace, nicméně > existují i jiné jako Jython, PyPy, IronPython, které například nemají GIL a > jsou tuším kompilované pro své virtuální stroje. > > GIL je kapitola sama pro sebe, k té se nechci vyjadřovat. Viděl jsem pitomě > napsanou funkci, kterou autor demonstroval, že Python neumí paralélní > výpočty. Doporučuji tento starý článek: > https://jeffknupp.com/blog/2012/03/31/pythons-hardest-problem/ > > > Co se týče rychlosti, tak Python podle Guida nikdy nekladl rychlost na první > místo. Existuje NumPy, Cython, Numba, které toto řeší, pokud má člověk > takovou potřebu. > https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en > > ________________________________ > Od: Python <python-boun...@py.cz> za uživatele Vláďa Macek > <ma...@sandbox.cz> > Odesláno: 2. ledna 2017 21:01:06 > Komu: Konference PyCZ > Předmět: Re: [python] Too much freedom? > > Děkuju za dosavadní odpovědi. > > Určitě jsou zajímavý, ale tak nějak mám pocit, že jste se nezdrželi na > podstatě otázky. :-) > > Nebo si to mám jednoznačně vyložit jako "svobodnou dynamičnost jazyka > neomezovat, protože zmíněný hypotetický zisky ve skutečnosti většina > nevyužije nebo je možné jich dosáhnout jinak"? > > Víte, mě se vždy líbila myšlenka RISC v obklopení bloatem CISC. Přemýšlím, > jestli Python trochu nezakopává o svojí nespoutanost ve chvíli, kdy záměrem > je psát v něm opravdu velký => konzistentní a stabilní systém. Vím, že se v > něm (úspěšně) píšou. > > Pythoní packaging taky vnímám jako něco, do čeho nechci vstupovat. Bolest. > Napadlo mě, jestli její kořeny netkví už třeba u importování, sys.path, > opět nespoutaném a tudíž nejednotném. > > Nemusíte mě nutně brát doslova, uvažuju. > > V. > > > On 2.1.2017 20:19, Michal Vyskocil wrote: >> Ahoj, >> >> Souhlasím, že gil je větší problém. Na rychlost je pypy, volitelné >> typování už fanda standardní knihovna. >> >> Já bych za sebe přidal lepší a jednodušší packaging, než setup.py, >> setup.cfg, manifest, requirements.txt a všechny ty věci. >> >> Nevím jak pro ostatní, ale pro mě je setuptools čirá magie. Jakékoli >> rozšířeni, třeba o py.test, je jenom o hledání magických postupů na >> internetu. >> >> Michal >> >> Dne 2. 1. 2017 6:18 PM napsal uživatel "Petr Messner" >> <petr.mess...@gmail.com <mailto:petr.mess...@gmail.com>>: >> >> Ahoj, >> >> mě to všechno zatím řeší Cython :) Když teda potřebuju rychlost. >> >> Zrychlení o 20% (nebo 25% nebo 50%...) - opravdu by to něčemu >> prakticky pomohlo? Jen málokdo funguje v takových rozměrech, aby 20% >> zrychlení Pythonu znamenalo, že se ušetří vůbec nějaké množství >> nákladů na hardware. >> >> Mě by se Python třeba výrazně zrychlil odstraněním GILu :) >> >> Jako já žádné zrychlovací snahy nechci shazovat, pokud to jde, tak >> sem s tím :) Jen prostě pokud za odpověď někdo považuje "zrychlit >> Python", jaká je vlastně otázka? A není na ní lepší odpověď? :) Třeba >> změnit databázové schéma, kešovat, jinak zpracovávat data, snížit >> počet I/O operací, použít nějakou hustou knihovnu, co využívá >> vektorové instrukce CPU/GPU... Nejspíš existují i jiné možnosti, než >> dojdete k okamžiku "a teď už by tomu opravdu pomohla jen kvantová JIT >> VM". >> >> Ad statická kontrola kódu - můžu začít tím, že si sem a tam budu >> anotovat, že funkce vrací string, nebo že to nějaký nástroj dokonce >> odvodí za mě... Ale čím vic jdu do hloubky, tím víc si říkám, že bych >> to teda raději dělal rovnou v tom C++ :) Ale to je možná tím, že >> jakmile mám kladivo (C++), tak prostě všechno najednou vypadá jako >> hřebík. I v tom Google si raději vymysleli Go, než aby každého >> programátora museli zasvěcovat do tajů C++. >> >> Jsem zvědavý na další názory :) Hodně zdraví a málo segfaultů v novém >> roce! >> >> PM >> >> Dne 2. ledna 2017 17:12 Vláďa Macek <ma...@sandbox.cz >> <mailto:ma...@sandbox.cz>> napsal(a): >> >> Ahoj všem, hezký nový rok. >> >> Občas mě napadne... >> Python je silně dynamický jazyk, tj. umožňuje velmi svobodné >> operace s >> objekty, metaprogramování atp. Až tolik, že to některým lidem >> přijde moc a >> vyvíjejí aktitivy, jak ho trochu spoutat a něco za to získat. >> >> Otázka. Obětovali byste některý z dynamických rysů pythonování >> výměnou >> třeba za (hypotetické) zisky, jako aby mainstreamový interpret >> >> * se všem zrychlil v průměru o 15% či o 20%? >> * se dal kompilovat do efektivního nativního kódu? >> * umožňoval výrazně lepší podporu automatické statické kontroly >> kódu? >> * ... >> >> Podotýkám, že to jsou podněty k zamyšlení, nikoli k flamewar. :-) >> >> Pokud máte načteno a ozkoušeno něco z toho, co se tématu týká, >> uvítám i, >> pokud se o to podělíte. Nikdy nezaškodí si rozšířit obzory. >> >> Vláďa >> >> >> _______________________________________________ >> Python mailing list >> python@py.cz <mailto:python@py.cz> >> http://www.py.cz/mailman/listinfo/python >> <http://www.py.cz/mailman/listinfo/python> >> >> Visit: http://www.py.cz >> >> >> >> _______________________________________________ >> Python mailing list >> python@py.cz <mailto:python@py.cz> >> http://www.py.cz/mailman/listinfo/python >> <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 > > > -- > : Vlada Macek : http://macek.sandbox.cz : +420 608 978 164 > : UNIX && Dev || Training : Python, Django : PGP key 97330EBD > > (Disclaimer: The opinions expressed herein are not necessarily those > of my employer, not necessarily mine, and probably not necessary.) > > _______________________________________________ > 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