[python] Too much freedom?
Honza Král
honza.kral na gmail.com
Úterý Leden 3 15:05:11 CET 2017
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.kral na gmail.com
Phone: +420 606 678585
2017-01-03 14:42 GMT+01:00 Pavel Řihošek <pavel.rihosek na 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-bounces na py.cz> za uživatele Vláďa Macek
> <macek na 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.messner na gmail.com <mailto:petr.messner na 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 <macek na sandbox.cz
>> <mailto:macek na 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 na py.cz <mailto:python na 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 na py.cz <mailto:python na 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 na 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 na py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
>
> _______________________________________________
> Python mailing list
> python na py.cz
> http://www.py.cz/mailman/listinfo/python
>
> Visit: http://www.py.cz
Další informace o konferenci Python