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
