Re: [python] Too much freedom?

[Matěj Cepl]

On 2017-01-03, 13:42 GMT, Pavel Řihošek wrote:
> Kontrolu kódu umí i PyCharm.

A samozřejmě i kterýkoli z pluginů pro textové editory (např.  
https://github.com/vim-syntastic/syntastic/ ).

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Two things fill the heart with renewed and increasing awe and
reverence the more often and the more steadily that they are
meditated on: the starry skies above me and the moral law inside
me.
-- Immanuel Kant: Critique of Practical Reason
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Too much freedom?

[Adam Štrauch]

> Pripada mi to podobny udaj, jako zrychleni z 0 na 100km/h u aut

Tohle je špatné přirovnání, protože i když to nevnímáš, tak to číslo je
důležitý a řekne ti, jak bude to auto vlastně jezdit. On výkon sám o sobě
je k ničemu, když neznáš váhu celého auta. Když pak pojedeš za kamionem a
nebudeš ho kvůli vlastnostem auta moct předjet, tak tě to dostane nejen do
nebezpečných situací, ale samotného tě to bude frustrovat. A takový efekt
to 15% zrychlení rozhodně nemá. Ale jak naznačuješ, tak není prakticky
poznat a myšlenka je dobrá.

Ve firmě, kde jsem dřív pracoval, se řešil hodně výkon PHP, protože tam v
něm byl, bůh ví proč, napsán program, co jede i 20 hodin v kuse. No a tak
zajásali, když mělo přijít PHP 7 se svým brutálním zrychlením. Nakonec se
ukázalo, že to to jede úplně stejně rychle, jen to potřebuje méně času na
procesoru a méně paměti. Jenže paměti i procesorových jader měli hodně a to
co se uvolnilo tu databázi stejně nezrychlilo a tak byli tam kde předtím, u
špatného návrhu.

Python je v porovnání s ostatními někdy i výrazně pomalejší, ale v dnešním
světě je jedno, jestli to běží na jednom nebo třech serverech. Drahý je
čas, který vývoj appky potřebuje a těch dvacet dolarů za servery už nikoho
nepálí. Jediné co se bude honit je odezva, ale to už podle mě nemá nic
společného s jazykem a jeho výkonem.

K původní otázka bych chtěl říct jen NE, nevyměnil bych to. Jediné co mi na
Pythonu vadí je to, že se zatím nepoužívají plošně anotace. Až se používat
budou, tak mi to v PyCharmu zjednoduší vývoj.

Dne 3. ledna 2017 23:34 Ales Zoulek  napsal(a):

> Padlo to tu ruznymi slovy nekolikrat, tak jen pro poradek.
>
> Zrychleni 15-20 % je pro me umely a vlastne zbytecny cislo, ktery
> "neskaluje". Mnohem dulezitejsi je moznost paralelizace a citelost
> ("spravovatelnost") kodu. Jak z pohledu vykonu, tak z toho ekonomickeho.
>
> Pripada mi to podobny udaj, jako zrychleni z 0 na 100km/h u aut.
> Teoreticky zajimavy benchmark, ale v realnym provozu me vice zajima
> maximalni komfortni rychlost, manevrovatelnost a pohodli.
>
>
> Zdravim,
>
> Ales.
>
> On Tue, Jan 3, 2017 at 10:43 PM Honza Javorek 
> wrote:
>
>> Jen dodám, že balíčkování a velikost stdlib vnímám jako dvě oddělené věci.
>>
>> HJ
>>
>> 2017-01-03 11:24 GMT+01:00 Matěj Cepl :
>>
>> On 2017-01-02, 19:53 GMT, Honza Javorek wrote:
>> > Nechci moc odbíhat, ale co existuje PyPA a vyvíjí to, plus píše
>> > https://packaging.python.org/, tak se v tom balíčkování jde orientovat
>> > trochu lépe, ale pořád je to nebe a dudy oproti např. (já vím, mladšímu)
>> > npm. Za mě je to taky momentálně největší bolest Pythonu.
>>
>> a) Mohl bys prosím trochu rozpracovat to „nebe a dudy“? Mám teď
>>v M2Crypto setup.py o 311 řádcích, ale marně přemýšlím, jak
>>bych to, co tam dělám, dělal s package.json. To je stejné
>>jako s gitem: to že jeden nástroj je schopný neuvěřitelných
>>triků (byť s poněkud komplikovaným API) není nevýhoda oproti
>>nástrojům, které něčeho takového ani vzdáleně schopni nejsou
>>(aneb stížnosti uživatelů SVN proti tomu, jak je komplikovaná
>>práce s git rebase -i ;))
>>
>> b) Kdykoli někdo začně srovnávat balíčkování Pythonu s NPM, tak
>>se jenom krátce zamyslím nad standardní knihovnou NodeJS
>>(respektive toho, že v podstatě neexistuje), popřemýšlím nad
>>balíčkem left-pad
>>(https://github.com/stevemao/left-pad/blob/master/index.js),
>>který polámal tisíce website, když byl stažen z NPM (včetně
>>Spotify, Netflix, atp.), a pak jsem zase velmi vděčen za
>>Python a jeho standardní knihovnu.
>>
>> Hezký nový rok!
>>
>> Matěj
>>
>> --
>> https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
>> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>>
>> We are told that [St. Anthony] once fell into dejection, finding
>> uninterrupted contemplation above his strength; but was taught to
>> apply himself at intervals to manual labour by a vision of an
>> angel who appeared platting mats of palm-tree leaves, then rising
>> to pray, and after some time sitting down again to work; and who
>> at length said to him, "Do thus, and thou shalt be saved."
>> -- Life of St. Anthony
>> ___
>> 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
>



-- 
Adam Štrauch
Roští.cz  | +420 777 63 63 88
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Too much freedom?

[Ales Zoulek]

Padlo to tu ruznymi slovy nekolikrat, tak jen pro poradek.

Zrychleni 15-20 % je pro me umely a vlastne zbytecny cislo, ktery
"neskaluje". Mnohem dulezitejsi je moznost paralelizace a citelost
("spravovatelnost") kodu. Jak z pohledu vykonu, tak z toho ekonomickeho.

Pripada mi to podobny udaj, jako zrychleni z 0 na 100km/h u aut. Teoreticky
zajimavy benchmark, ale v realnym provozu me vice zajima maximalni
komfortni rychlost, manevrovatelnost a pohodli.


Zdravim,

Ales.

On Tue, Jan 3, 2017 at 10:43 PM Honza Javorek  wrote:

> Jen dodám, že balíčkování a velikost stdlib vnímám jako dvě oddělené věci.
>
> HJ
>
> 2017-01-03 11:24 GMT+01:00 Matěj Cepl :
>
> On 2017-01-02, 19:53 GMT, Honza Javorek wrote:
> > Nechci moc odbíhat, ale co existuje PyPA a vyvíjí to, plus píše
> > https://packaging.python.org/, tak se v tom balíčkování jde orientovat
> > trochu lépe, ale pořád je to nebe a dudy oproti např. (já vím, mladšímu)
> > npm. Za mě je to taky momentálně největší bolest Pythonu.
>
> a) Mohl bys prosím trochu rozpracovat to „nebe a dudy“? Mám teď
>v M2Crypto setup.py o 311 řádcích, ale marně přemýšlím, jak
>bych to, co tam dělám, dělal s package.json. To je stejné
>jako s gitem: to že jeden nástroj je schopný neuvěřitelných
>triků (byť s poněkud komplikovaným API) není nevýhoda oproti
>nástrojům, které něčeho takového ani vzdáleně schopni nejsou
>(aneb stížnosti uživatelů SVN proti tomu, jak je komplikovaná
>práce s git rebase -i ;))
>
> b) Kdykoli někdo začně srovnávat balíčkování Pythonu s NPM, tak
>se jenom krátce zamyslím nad standardní knihovnou NodeJS
>(respektive toho, že v podstatě neexistuje), popřemýšlím nad
>balíčkem left-pad
>(https://github.com/stevemao/left-pad/blob/master/index.js),
>který polámal tisíce website, když byl stažen z NPM (včetně
>Spotify, Netflix, atp.), a pak jsem zase velmi vděčen za
>Python a jeho standardní knihovnu.
>
> Hezký nový rok!
>
> Matěj
>
> --
> https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> We are told that [St. Anthony] once fell into dejection, finding
> uninterrupted contemplation above his strength; but was taught to
> apply himself at intervals to manual labour by a vision of an
> angel who appeared platting mats of palm-tree leaves, then rising
> to pray, and after some time sitting down again to work; and who
> at length said to him, "Do thus, and thou shalt be saved."
> -- Life of St. Anthony
> ___
> 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] Too much freedom?

[Honza Javorek]

Jen dodám, že balíčkování a velikost stdlib vnímám jako dvě oddělené věci.

HJ

2017-01-03 11:24 GMT+01:00 Matěj Cepl :

> On 2017-01-02, 19:53 GMT, Honza Javorek wrote:
> > Nechci moc odbíhat, ale co existuje PyPA a vyvíjí to, plus píše
> > https://packaging.python.org/, tak se v tom balíčkování jde orientovat
> > trochu lépe, ale pořád je to nebe a dudy oproti např. (já vím, mladšímu)
> > npm. Za mě je to taky momentálně největší bolest Pythonu.
>
> a) Mohl bys prosím trochu rozpracovat to „nebe a dudy“? Mám teď
>v M2Crypto setup.py o 311 řádcích, ale marně přemýšlím, jak
>bych to, co tam dělám, dělal s package.json. To je stejné
>jako s gitem: to že jeden nástroj je schopný neuvěřitelných
>triků (byť s poněkud komplikovaným API) není nevýhoda oproti
>nástrojům, které něčeho takového ani vzdáleně schopni nejsou
>(aneb stížnosti uživatelů SVN proti tomu, jak je komplikovaná
>práce s git rebase -i ;))
>
> b) Kdykoli někdo začně srovnávat balíčkování Pythonu s NPM, tak
>se jenom krátce zamyslím nad standardní knihovnou NodeJS
>(respektive toho, že v podstatě neexistuje), popřemýšlím nad
>balíčkem left-pad
>(https://github.com/stevemao/left-pad/blob/master/index.js),
>který polámal tisíce website, když byl stažen z NPM (včetně
>Spotify, Netflix, atp.), a pak jsem zase velmi vděčen za
>Python a jeho standardní knihovnu.
>
> Hezký nový rok!
>
> Matěj
>
> --
> https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> We are told that [St. Anthony] once fell into dejection, finding
> uninterrupted contemplation above his strength; but was taught to
> apply himself at intervals to manual labour by a vision of an
> angel who appeared platting mats of palm-tree leaves, then rising
> to pray, and after some time sitting down again to work; and who
> at length said to him, "Do thus, and thou shalt be saved."
> -- Life of St. Anthony
> ___
> 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] Too much freedom?

[Matěj Cepl]

On 2017-01-02, 19:53 GMT, Honza Javorek wrote:
> Nechci moc odbíhat, ale co existuje PyPA a vyvíjí to, plus píše
> https://packaging.python.org/, tak se v tom balíčkování jde orientovat
> trochu lépe, ale pořád je to nebe a dudy oproti např. (já vím, mladšímu)
> npm. Za mě je to taky momentálně největší bolest Pythonu.

a) Mohl bys prosím trochu rozpracovat to „nebe a dudy“? Mám teď 
   v M2Crypto setup.py o 311 řádcích, ale marně přemýšlím, jak 
   bych to, co tam dělám, dělal s package.json. To je stejné 
   jako s gitem: to že jeden nástroj je schopný neuvěřitelných 
   triků (byť s poněkud komplikovaným API) není nevýhoda oproti 
   nástrojům, které něčeho takového ani vzdáleně schopni nejsou 
   (aneb stížnosti uživatelů SVN proti tomu, jak je komplikovaná 
   práce s git rebase -i ;))

b) Kdykoli někdo začně srovnávat balíčkování Pythonu s NPM, tak 
   se jenom krátce zamyslím nad standardní knihovnou NodeJS 
   (respektive toho, že v podstatě neexistuje), popřemýšlím nad 
   balíčkem left-pad 
   (https://github.com/stevemao/left-pad/blob/master/index.js), 
   který polámal tisíce website, když byl stažen z NPM (včetně 
   Spotify, Netflix, atp.), a pak jsem zase velmi vděčen za 
   Python a jeho standardní knihovnu.

Hezký nový rok!

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
We are told that [St. Anthony] once fell into dejection, finding
uninterrupted contemplation above his strength; but was taught to
apply himself at intervals to manual labour by a vision of an
angel who appeared platting mats of palm-tree leaves, then rising
to pray, and after some time sitting down again to work; and who
at length said to him, "Do thus, and thou shalt be saved."
-- Life of St. Anthony
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Too much freedom?

[Pavel Řihošek]

Co se týče té statické kontroly, lidé si často pletou statickou typovou 
kontrolu s silným typovým systémem. Házejí pak do jednoho pytle Javascript a 
PHP s Pythonem, aniž by si uvědomili, že Python je jiná bestie, jak říkají na 
anglických fórech :)

Ostatně, stačí si vzpomenout na slavnou: "Null References: The Billion Dollar 
Mistake". A tady rozhodně řádné statické typování nepomůže.

Jinak je docela srandovní, jak se může měnit úhel pohledu, stačí stát na 
správné straně. Pro Fsharpisty například je statická kontrola v C# 
nedostatečná, v čemž mají ostatně pravdu.

Jestliže chceš, Petře, bezpečný a kompilovaný jazyk s řadou výhod, jdi do 
Fsharpu. V zásadě napravuje všechno, co vytýkáš Pythonu.

Sumu výhod ale zaplatíš sumou nevýhod. Menší komunita, žádné "battery 
included", náročnější na bednu atd.

Jak napsal Honza Král, statická kontrola je do určité míry mýtus. Staticky 
typovaný Typescript může krásně vybouchnout na slabém typovém systému 
Javascriptu, protože Typescript je nadmnožinou Javascriptu.

Samotný Python se v tomto směru aktivně vyvíjí.

Kromě zmíněného mypy, můžu jmenovat:
https://docs.python.org/3.5/library/abc.html
https://docs.python.org/3/library/typing.html

Kromě toho má vynikající lintery atd.

Ale k čemu to je, když lidé netuší, že nějaké anotace a mypy existují, lintery 
nepoužívají a testy nepíší.
Místo toho ala Java musí všechno strkat do tříd, které ani nedokáží otestovat, 
protože bez OOP to přece nejde. Když se potom v tom zmatku nevyznají, je chyba 
v dynamické povaze Pythonu :)






Od: Python <python-boun...@py.cz> za uživatele Petr Messner 
<petr.mess...@gmail.com>
Odesláno: 3. ledna 2017 15:22
Komu: Konference PyCZ
Předmět: Re: [python] Too much freedom?

Dne 2. ledna 2017 18:18 Petr Messner 
<petr.mess...@gmail.com<mailto:petr.mess...@gmail.com>> napsal(a):
Mě by se Python třeba výrazně zrychlil odstraněním GILu :)


Samozřejmě jsem chtěl napsat CPython :)

PM
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Too much freedom?

[Petr Messner]

Dne 2. ledna 2017 18:18 Petr Messner  napsal(a):

> Mě by se Python třeba výrazně zrychlil odstraněním GILu :)
>
>
Samozřejmě jsem chtěl napsat CPython :)

PM
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Too much freedom?

[Honza Král]

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
&

Re: [python] Too much freedom?

[Pavel Řihošek]

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...
> 

Re: [python] Too much freedom?

[Vláďa Macek]

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"
> >:
>
> 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  > 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 
> 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


-- 
: 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 

Re: [python] Too much freedom?

[Honza Javorek]

Nechci moc odbíhat, ale co existuje PyPA a vyvíjí to, plus píše
https://packaging.python.org/, tak se v tom balíčkování jde orientovat
trochu lépe, ale pořád je to nebe a dudy oproti např. (já vím, mladšímu)
npm. Za mě je to taky momentálně největší bolest Pythonu.

HJ

2017-01-02 20:19 GMT+01:00 Michal Vyskocil :

> 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>:
>
> 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  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
>> 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
>
___
Python mailing list
python@py.cz
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz

Re: [python] Too much freedom?

[Michal Vyskocil]

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>:

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  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
> 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] Too much freedom?

[Petr Messner]

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  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
> 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] Too much freedom?

[Vláďa Macek]

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
http://www.py.cz/mailman/listinfo/python

Visit: http://www.py.cz