Re: [python] Too much freedom?

2017-01-02 Tema obsahu 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?

2017-01-02 Tema obsahu 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?

2017-01-02 Tema obsahu 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?

2017-01-02 Tema obsahu 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?

2017-01-02 Tema obsahu 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