PHP 7.0.0

Byla vydána verze 7.0.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Nejnovější větev PHP přináší novou verzi Zend Enginu, řadu vylepšení a nových vlastností. Dle oznámení může být PHP 7 až dvakrát rychlejší než PHP 5.6 a má výrazně nižší paměťové nároky. K dispozici je příručka pro přechod z PHP 5.6.x na PHP 7.0.x.

3.12.2015 23:40 | Ladislav Hagara | Nová verze

Komentáře

[onovy]

PHP 7 dvakrát rychlejší než PHP 5.6

PHP 7 is up to twice as fast as PHP 5.6

a takto vznikaji novinarske kachny...

[Ladislav Hagara]

Dík, opraveno.

[Radovan]

Konečně důstojná náhrada za Javu.

[radix]

lol

[termixator]

nevím, jestli se mám zasmát, protože trolíš, nebo mi tě má být líto, protože tomu věříš

[Pavel Půlpán]

Třeba jenom nedostatek nebo naopak přebytek prášků...

[Olaf]

Programátoři v PHP, poraďte: jaké praktické a výkonnostní výhody má PHP nad Pythonem? Ne vážně, nechci trollovat, ale dělám léta v Pythonu a poslední roky v Djangu (pythonovský framework pro web). Otázka zní, proč (a jak?) se učit nové PHP? PHP je sice rozšířenější (mluvě o webu), ale také plat za takovou práci se pohybuje kol výše nástupního platu skladníka. Přitom mi přijde, že PHP je min. o řád složitější a ukecanější ("verbose", jako ostatní C-like jazyky) než Python/Django (tj. více práce za méně peněz). Navíc (co se mě týče), téměř nulová podpora matematických a vědeckých knihoven (fajn, to je úzký obor, ale stejně). Je to prostě jen o tom, že u PHP je větší poptávka, byť za zlomkový honorář/plat, i když je s tím více práce?

[Josef Kufner]

Je to jedno. Typicky ty aplikace nejsou tak náročné, aby výkon obou jazyků byl problém.

[kyknos]

technicka vyhoda asi zadna... ale hosting s php je mnohem dostupnejsi, popularni cms jsou v php atd... proste v praxi na php clovek narazi porad

[Jendа]

jaké praktické a výkonnostní výhody má PHP nad Pythonem?

Za sebe: nenašel jsem pro Python něco, co by dělalo FastCGI server, a umožnilo do existujících HTML stránek vložit krátký snippet Pythoního kódu, prostě stejně jako PHP: <?python print("Hello world") ?>. Když se někde zeptám, tak mi všichni začnou říkat, že Python ví lépe než já co chci, tedy že potřebuji komplexní šablonovací systém, a že nepotřebuji webserver, protože Python má přece vestavěný, a že každá stránka má mít vlastní rezidentní proces, který jí bude dělat webserver.

[Bystroushaak]

bottle.py a SimpleTemplate engine? Není to úplně ‚out of the box‘ řešení, ale imho to funguje velmi podobně tomu, co bys asi chtěl.

[Jendа]

Hm, to nevypadá, že by umělo žrát jednotlivé soubory (nedejbože napříč virtualhosty), všichni nastaví přes @route('/') několik URL a pak to na to pošlou přes HTTP nebo fcgi přes flup.

[Jendа]

Napsal jsem si do Bottle aplikaci, která z request.url uhodne, kde leží soubor, na který jsem to volal (/var/www/doména/cesta), přečte ho a vrazí do template. S tím by se dalo žít, ale 1) neumím z templaty vypsat generický výpis (print() píše samozřejmě do konzole), 2) odpověď to pošle až celou najednou po tom, co je template hotová. Takže nedokážu implementovat partial content.

[Jendа]

Takže nedokážu implementovat partial content.

Nejmenuje se to takhle. Use-cases:

• Napsal jsem online tetrapol decoder, kde trvá, než se požadavek zpracuje. Když v PHP vypíšu status a udělám flush, uživatel ho dostane.
• Můžu uživateli updatovat v browseru obrázek tak, že mu pošlu multipart/x-mixed-replace, a pak mu postupně posílám ty sekce.

[Michal Kubeček]

Chunked encoding?

[mirec]

Na prúdové spracovanie ja dobré tornado / cyclone.

[Bystroushaak]

neumím z templaty vypsat generický výpis (print() píše samozřejmě do konzole)

Budeš si muset print() redefinovat tak, aby psal do té templaty. Když se kouknu na zdroják, tak se tomu předává jakýsi _stdout parametr, zkus schválně co se stane, když do něj zapíšeš. Netvrdím ale, že to půjde, ostatně je to SimpleTemplate. V tomhle ohledu by možná bylo lepší použít nějakou z alternativ, jako třeba zmiňovaná jinja2 (tam by to podle rychlého googlení mělo jít přes Custom Filters).

Takže nedokážu implementovat partial content.

V bottle je objekt response. Pro inspiraci viz toto: Is it possible to use gzip compression with Server-Sent Events (SSE)?

[Mintaka]

Re. <? python print("Hello world") ?>:

Možná je to tím, že v Pythonu lze udělat webserver na 7 řádek kódu a pak už si můžete parsovat vaše soubory jak je libo. https://docs.python.org/2/library/simplehttpserver.html

V časech kompilovaných CGI scriptů bylo PHP docela šikovným nástrojem. Léta mi dobře sloužilo. Pár historických věcí na něm držím do dnes. Pak se to ale nějak začalo kazit. Nějak jsem neměl sílu snášet ty přešlapy, když se PHP snažilo vyrůst z (Private Home Page) někam dál. .Net nebo Java to byly na slabším HW nepříjemní bumbrlíčci. Takže jsem také zakotvil u Pythonu. Plone (Zope) byl sice taky pořádný macek, ale daly se z něj vybrat jen potřebné knihovny. Do Djanga jsem nastoupil lehce před verzí 0.96 a nelitoval jsem.

Chybí-li vám hosting pro Python, doporučuji vyzkoušet Google App Engine. S trochou snahy se dá i web pro pár set uživatelů vměstnat do free quotas. IMHO na větší věci je, dle mého, lepší mít pod kontrolou vlastní server, nebo aspoň VPS.

Až mě Python naštve (má své mouchy, jako všecko), třeba dám PHPčku šanci, ale do vod server side scriptů připlouvají i další štiky.

Ať se daří.

[Bystroushaak]

Všímáš si, že děláš přesně to, na co si Jenda stěžoval? Navíc nevím, proč uvádíš ještě simplehttpserver, což je totální toy projekt dobrý tak leda na nějaké pokusy, nebo když člověk rychle potřebuje způsob, jak přenést soubory mezi dvěma počítači.

[Mintaka]

re. Všímáš si, že děláš přesně to, na co si Jenda stěžoval?: Vůbec jsem si nevšimnul, že by si Jenda na něco stěžoval.

Simplehttpserver mě napadl, jako první řešení toho, jak docílit, aby mi HTTP server interpretoval <?Python print("hello") ?> jako pythonovský kód. Samozřejmě, pro rozumné produkční řešení to není.

Na přesměrování stdout jde použít contextlib.

Jinak na CGI řešení s Pythonem je celá řada projektíčků. Např: http://www.sallyx.org/sally/python/python16.php Nevím o tom, že by se některé ve větší míře používalo.

[Jendа]

Simplehttpserver mě napadl, jako první řešení toho, jak docílit, aby mi HTTP server interpretoval <?Python print("hello") ?> jako pythonovský kód.

Ale ten SimpleHTTPServer jenom servíruje soubory, interpretaci bych si musel napsat.

Jinak na CGI řešení s Pythonem je celá řada projektíčků.

Já chtěl FastCGI, protože a) bych si musel napsat parser (což by nebylo tak těžké), b) bych musel nějak vyřešit, aby se při každém requestu nespouštěl nový pythoní interpret.

Pro Apache existuje mod_python, ale já na většině serverů nemám Apache. Asi budu reverzovat ten mod_python, jak udělat, aby to nespouštělo nový interpret při každém požadavku.

[Bystroushaak]

Vůbec jsem si nevšimnul, že by si Jenda na něco stěžoval.

Viz:

Když se někde zeptám, tak mi všichni začnou říkat, že Python ví lépe než já co chci, tedy že potřebuji komplexní šablonovací systém

Na což jsi mu řekl, ať si implementuje šablonovací systém.

a že nepotřebuji webserver, protože Python má přece vestavěný

A pak mu doporučil vestavěný simplehttpserver.

[Mintaka]

RE.vestavěný simplehttpserver: A nemůže být info o 7 řádcích kódu vysvětlení, proč mu lidi doporučují embeded server?

Jinak o Pythonu a FastCGI se dá něco najít. Nakolik je to použitelné netuším.

http://www.electricmonk.nl/docs/apache_fastcgi_python/apache_fastcgi_python.html

https://blogs.oracle.com/oswald/entry/good_idea_python_with_fastcgi

[Jendа]

A nemůže být info o 7 řádcích kódu vysvětlení, proč mu lidi doporučují embeded server?

Došlo mi, že by mi bylo asi fuk, jestli to je webserver nebo fastcgi server (jen nevím, jestli u webserveru umí lighttpd a Apache chunked jak jsem psal výše). Jenže druhý problém je, že ani to řešení s webserverem nedělá to, co jsem požadoval.

Jinak o Pythonu a FastCGI se dá něco najít. Nakolik je to použitelné netuším.

Ani jeden z těch návodů nesplňuje mé původní požadavky, jedná se o separátně běžící konkrétní aplikaci. Nemohu mít pro každý skript spuštěný proces.

Tímto způsobem by to šlo leda že bych spustil toto a to by byl parser, který by dělal eval() dalších souborů. Přijde mi to přes ruku, ale v Pythonu se mi programuje o tolik líp než v PHP, že to asi zkusím.

[Bystroushaak]

Ani jeden z těch návodů nesplňuje mé původní požadavky, jedná se o separátně běžící konkrétní aplikaci. Nemohu mít pro každý skript spuštěný proces.

Zkoušel jsi ten bottle? Ten má FastCGI rozhraní, přes které se umí připojit na „velké“ servery jako nginx, ale umí běžet i jako docela postačující server (běží na tom třeba moje stránky).

Tímto způsobem by to šlo leda že bych spustil toto a to by byl parser, který by dělal eval() dalších souborů. Přijde mi to přes ruku, ale v Pythonu se mi programuje o tolik líp než v PHP, že to asi zkusím.

Prostě přečteš soubor, který přišel v URL, spustíš nad ním template engine a vrátíš zbytek. Asi by nebylo od věci to napsat jako framework, když je po tom taková poptávka. Píšu si do todo.

[Jendа]

spustíš nad ním template engine

To mi právě nejde, protože to čeká, až template engine doběhne, a pak to teprve vrátí výsledek.

Asi by nebylo od věci to napsat jako framework, když je po tom taková poptávka.

Nevím o nikom jiném než jsem já, kdo by to chtěl.

[Bystroushaak]

Nevím o nikom jiném než jsem já, kdo by to chtěl.

Kdysi jsem to chtěl taky, tak jsem googlil a našel jsem docela hodně stackoverflow threadů, kde to lidi taky poptávají.

To mi právě nejde, protože to čeká, až template engine doběhne, a pak to teprve vrátí výsledek.

Aha. Tak tohle se bude řešit docela blbě. Jediné, co mě napadá je nedělat to v template engine, protože fakt nevím o žádném, který by umožňoval proudové renderování (ale v tomhle nejsem zrovna dvakrát odborník, mirec dělá weby, tak možná bude vědět víc).

[mirec]

Jinja2 má TemplateStream.

[Jendа]

Mimochodem v PHP je webserver na 0 nebo 1 řádek kódu, podle toho, jak to počítáš (php -S). Tyhle embedded webservery mají ale problém v tom, že nemají žádné pokročilejší konfigurační volby, takže jim člověk stejně musí předřadit „skutečný“ webserver.

[Bystroushaak]

Mimochodem v PHP je webserver na 0 nebo 1 řádek kódu, podle toho, jak to počítáš (php -S).

Imho nemá smysl srovnávat jazyk s modulem pro apache. V PHP jako jazyku taky webserver nebude žádná slává. V PHP jako frameworku je to o něčem jiném, ale to pro python taky.

Tyhle embedded webservery mají ale problém v tom, že nemají žádné pokročilejší konfigurační volby, takže jim člověk stejně musí předřadit „skutečný“ webserver.

Já konkrétně používám bottle přímo jako webserver s backendem paste (zajišťuje multithreading).

[Josef Kufner]

Ten webserver v PHP je určený k testování, ne na produkční provoz. Na to je php-fpm – FastCGI Process Manager v kombinaci s nginx či podobným serverem.

[Jendа]

Možná je to tím, že v Pythonu lze udělat webserver na 7 řádek kódu a pak už si můžete parsovat vaše soubory jak je libo. https://docs.python.org/2/library/simplehttpserver.html

A dalších kdovíkolik řádek musím vymyslet, aby mi můj současný webserver při požadavku na soubor.py tento přesměroval na tento pythoní server a ten běžel ve správném adresáři (v tom, ve kterém je ten soubor).

V časech kompilovaných CGI scriptů bylo PHP docela šikovným nástrojem.

Mně by nevadilo, kdyby se to kompilovalo, kompilaci si naskriptuju.

Nějak jsem neměl sílu snášet ty přešlapy, když se PHP snažilo vyrůst z (Private Home Page) někam dál.

Já nerozporuji, že PHP jako jazyk stojí za prd.

Chybí-li vám hosting pro Python

Nechybí, všechno mi běží na serverech, kde mám roota, takže si můžu cokoli nainstalovat a nastavit.

[pavlix]

Ty vkládané skripty jsou to, co se mi na PHP nejvíc nelíbí, takže osobně podhe toho vůbec nesrovnávám. Zatímco PHP je šablonovcím systémem samo o sobě, v Pythonu si vyberu šablonový systém a sahám do něj z hlavního programu, který zpracovává URL.

Ale pokud vím, tak smyslem FastCGI (kterým jsem před lety pythoní aplikace mimochodem běžně deployoval) je právě rezidentní proces pro každý jednotlivý web (nikoli stránku).

[Josef Kufner]

Ale pokud vím, tak smyslem FastCGI (kterým jsem před lety pythoní aplikace mimochodem běžně deployoval) je právě rezidentní proces pro každý jednotlivý web (nikoli stránku).

Ne tak docela. Navíc ještě řeší, zda ten proces musí běžet a jestli není lepší ho vypnout a spustit něco jiného. Navíc je tam takový drobný rozdíl v sémantice, kdy jednotlivé požadavky jsou pořád velmi izolované (až na nějaké to kešování). FastCGI je jen optimalizace obyčejného CGI, kde to je nový proces pro každý požadavek. Oproti tomu při trvale běžícím procesu se zachovává kontext mezi požadavky.

Kdyby Python měl něco jako PHP-FPM a bylo to běžně podporované na webhostinzích, bylo by to úplně o něčem jiném.

[Michal Kubeček]

FastCGI je jen optimalizace obyčejného CGI, kde to je nový proces pro každý požadavek.

Nový proces (tj. fork()) není až takový problém - a nový proces pro každý request může vznikat i u FastCGI (spíš by mne překvapilo, kdyby to nebyla většinová implementace). Podstatným problémem klasického CGI je ten execve(), který u klasického CGI následuje.

[Josef Kufner]

Krom samotného execve() jde hlavně o spojení k databázi, otevřené logy, načítání konfigurace a podobné inicializační věci, které trvají dlouho a které kvůli execve() neumí CGI uchovat mezi požadavky.

[Michal Kubeček]

Tím spíš je pak "nový proces pro každý požadavek" naprosto zanedbatelný problém.

[Konqui]

Vždyť má - uWSGI, případně jakékoliv WSGI.

[Josef Kufner]

A proč se tu tedy tajtrdlíkuje s psaním/spouštěním vlastního serveru?

[Konqui]

Tak to fakt netuším. Nicméně WSGI právě řeší forkování, procesy a vše okolo toho. Můžeš si nadefinovat kolik procesů má běžet trvale, kolik se jich může maximálně naforkovat a podobné záležitosti....

Používat vestavěné servery vy Pythonu na produkční nasazení je hovadina

[pavlix]

To asi není otázka na ty, co používají WSGI.

[Josef Kufner]

Spíš to je otázka na ty, kteří píšou tutoriály a dokumentaci a také na ty, kteří dělají balíčky.

[dush]

https://www.phusionpassenger.com/library/walkthroughs/start/python.html

https://www.phusionpassenger.com/library/walkthroughs/basics/python/

https://www.phusionpassenger.com/library/walkthroughs/deploy/python/

[mirec]

Ako človek, ktorý prešiel z PHP na django môžem povedať jedinú výhodu PHP - podpora hostingov. Čo sa týka výkonu python je prakticky rovnako výkonný ako node.js (ak sa použije pypy). Django je kapitola sama o sebe, výkon šablónovacieho systému je žalostný, ale dá sa ľahko vymeniť za jinja2.

[Bystroushaak]

Taky by mě zajímalo, proč by se někdo programující v pythonu učil nové PHP. Sám na to nemám dost perverzní fantazii.

[leoš]

ty se koukám prostě nechceš učit nic konzerva, v IT tě to brzy zabije

[COBOLFOREVER]

Ja uz 40 let programuju v COBOLU za plat, o kterem se Javistum a podobnym ani nezda, a nic noveho se ucit nepotrebuju.

[pavlix]

Ať už je to pravda nebo ne, tohle docela dobře chápu. :)

[Bystroushaak]

ty se koukám prostě nechceš učit nic konzerva, v IT tě to brzy zabije

Vážně? Kde na to koukáš? Taky bych se rád podíval *odloží self handbook a napjatě čeká*.

[R]

Ja robim v PHP lebo nemam rad objekty.

[skywaker]

PHP ma objekty a mnohe CMS ich vyuzivaju pricom aj prinasa to vyhody ake? oproti pythonu jedinu a to ze kod sa da znovupouzit inym sposobom nez by tomu bolo ak by si mal odniekial volat cez include naproti tomu pri objekte mozes vyuzivat stale tie zapuzdrene premene. je to sice dost osekane nielen oproti pythonu proste oproti kazdemu asi objektoemu jazyku ale da sa to vyuzit.

[R]

Neboj sa, velmi dobre viem, ze aj PHP ma objekty. Ale nenuti ma ich pouzivat (vacsinou).

[pavlix]

Objekty jsou všude, s OOP i bez OOP. :D

[Karlitos]

Nez se zacit ucit PHP, doporucoval bych alepson zbezne procist toto shrnuti Myslim ze nejvystizneji popisuje PHP jeden z komentaru pod clankem:

"PHP je jako Justin Bieber. Nemusite byt dobri k tomu abyste byli popularni"

[j3nda]

-1

[j3nda]

to "-1" bylo v reakci na "Ja robim v PHP lebo nemam rad objekty.", abych byl presny.

[j3nda]

+1 pro koment ""PHP je jako Justin Bieber. Nemusite byt dobri k tomu abyste byli popularni""

[tacoberu]

Neumíš-li PHP tak ti IMHO nic nepřinese. Pro mě ale je zásadní killerfeature (v protikladu k Pythonu) volitelná statická typová kontrola. DuctTyping v Pythonu mě může vždycky vzteknout.

[mirec]

Type hints

[Pavel Půlpán]

Třikrát hurá...

[Bystroushaak]

Je hezké vidět, že tentokrát se jim to podařilo. Když to zkoušeli minule, tak to skončilo špatně.

[alfonz]

Je vidět, že když se chce, tak to docela jde. Škoda, že Python, se také neubírá cestou zrychlení a ořezání zbytečností..

[mirec]

Vážne žiadne zrýchlenia? Jazyk, ktorý má 68 funkcií (pre porovnanie PHP má vyše 6000) potrebuje fakt orezávať zbytočnosti?

[alfonz]

Blbé, je že rychlost se zvyšuje u PYPY, ale ne u Pythonu3, který spíše "přidává". Nechápejte mě špatně, mám Python rád, ale spíše verzi 2.6-2.7, bohužel některé nové zpomalující výhody, mi zas tak jako nepřipadají.

[Bystroushaak]

Python3 není konkrétní produkt, jen specifikace. Asi máš na mysli CPython 3. Jinak by mě zajímalo, co jsou ty nové zpomalující výhody, osobně jsem o ničem neslyšel, ale rychlost zas tak moc nesleduji. A zrovna pypy má našlápnuto docela dobře, každou chvíli od nich vidím v rss zprávičku, že zase zrychlili o desítky procent něco.

[kyknos]

Moje, mnohokrat opakovana, zkusenost je, ze pri stejnem investovanem usili je muj kod v pythonu rychlejsi nez kod v cecku, jave apod. (Napsany mezitim fandou techto jazyku):) samozrejme proto, ze misto srani se s jazykem mam cas na samotny algoritmus. Takze to, ze je referencni implementace pythonu 3 o par procent pomalejsi mi fakt zily netrha a jsem rad, ze maji vyvojari pythonu priority jake maji

[Miloslav Ponkrác]

„Moje, mnohokrat opakovana, zkusenost je, ze pri stejnem investovanem usili je muj kod v pythonu rychlejsi nez kod v cecku, jave apod.“

Právě jsi splnil veškeré parametry pro nevěrohodnost s pravděpodobností 100 % a váhou plus nekonečno.

[kyknos]

lec je to proste tak

a neni to imho ani nic prekvapiveho, porovname-li vyjadrovaci schopnosti jazyku

(a skutecnosti, ze nepatlam nejake weby apod, ale resim ulohy, ktere jsou velmi citlive na vhodne navrzeny algoritmus)

[Bystroushaak]

Related: Why I use Python for writing high performance code

[Radek Miček]

Statický typový systém není jen k tomu, aby s ním programátor bojoval, ale aby ho využil ve svůj prospěch – například pro snazší orientaci v kódu, což pak vede na vyšší produktivitu.

[Bystroushaak]

Já bych prosil nějakou studii dokazující, že statický typový systém vede na vyšší produktivitu, protože zatím veškeré mé desetileté programátorské zkušenosti ukazují pravý opak. Ale třeba jsem žil v omylu a možnost omezení proměnné, aby mohla ukazovat jen na subset referencí je nějaká programátorská bonanza, kterou jsem zatím nepochopil.

[Radek Miček]

Já bych prosil nějakou studii dokazující, že statický typový systém vede na vyšší produktivitu, protože zatím veškeré mé desetileté programátorské zkušenosti ukazují pravý opak

Žádnou nemám. Nicméně nepodporuje mé tvrzení skutečnost, že Python přidal syntax pro typové anotace?

Dále, když máte bohatý statický typový systém s dobrou typovou inferencí, může vám IDE vypomoci při tvorbě kódu a při orientaci v kódu, aniž by to znamenalo znepřehlednění programu typovými anotacemi. V tzv. dynamicky typovaných jazycích máte sice větší volnost (například lze manipulovat s třídami za běhu), ale je tam větší riziko, že IDE těmto obratům neporozumí a nijak vám nepomůže.

[Radek Miček]

Kromě toho, typový systém brání některým chybám, na něž v tzv. dynamicky typovaných jazycích přijdete až za běhu – tím se vývoj zrychluje.

[Bystroushaak]

Kromě toho, typový systém brání některým chybám, na něž v tzv. dynamicky typovaných jazycích přijdete až za běhu

Ano, to uznávám.

– tím se vývoj zrychluje.

Neuznávám, že se tím vývoj zrychluje, protože stejně musím psát testy tak, jako tak.

[Radek Miček]

Neuznávám, že se tím vývoj zrychluje, protože stejně musím psát testy tak, jako tak.

Někdy stačí psát testů méně, protože může nastat méně situací (typy zamezí vzniku některých situací).

[Bystroushaak]

Žádnou nemám. Nicméně nepodporuje mé tvrzení skutečnost, že Python přidal syntax pro typové anotace?

Ne, to fakt nepodporuje. Do pythonu to bylo přidané po 26 letech spokojeného fungování hlavně kvůli „bezpečnosti“ a nápovědám funkcí v IDE (místo v docstringu to teď bude oblejzat definici funkce, třikrát hurá). Produktivitu jsem fakt nikde v diskuzích kolem toho, ani v PEPu neviděl.

Dále, když máte bohatý statický typový systém s dobrou typovou inferencí, může vám IDE vypomoci při tvorbě kódu a při orientaci v kódu, aniž by to znamenalo znepřehlednění programu typovými anotacemi.

Imho je nutné rozlišovat taky silné a slabé typové systémy. Python používá silné typování (objekt nikdy nemění typ) s dynamickými typy proměnných (proměnná může ukazovat na objekty libovolného typu a na co ukazuje lze později změnit). IDE pro python existují a fungují stejně dobře, jako třeba pro javu (viz pycharm). „Problém“ byl u funkcí, kde IDE může zkoušet odvodit podle kódu funkce co všechno lze do ní dát, a co už vyhodí výjimku. Běžně se to psalo do docstringů, teď se to bude moct volitelně psát kolem. Osobně v tom nevidím žádnou silnou výhodu a kdyby bylo na mě, tak bych tam tuhle featuru nepřidával, protože to kurví duck typing a původní ideu OOP, ve prospěch javovin.

[Radek Miček]

IDE pro python existují a fungují stejně dobře, jako třeba pro javu (viz pycharm).

Fungují dobře jen v případě, pokud je kód velmi jednoduchý nebo pokud mají speciální podporu pro použité knihovny (což platí jen pro značně rozšířené knihovny – pro ostatní knihovny máte smůlu). Například můžete zkusit napsat kód, který modifikuje nějaké třídy za běhu (třeba přidává nebo mění metody) a pozorovat, jak se s tím různá IDE vyrovnají.

Jinak řečeno, když v těch jazycích píšete jako v Javě, tak IDE fungují dobře. Když, ale začnete využívat skutečnost, že třídy jsou obyčejné hodnoty, a měnit je za běhu (čímž někdy lze ušetřit velké množství kódu), tak většina IDE selže.

„Problém“ byl u funkcí, kde IDE může zkoušet odvodit podle kódu funkce co všechno lze do ní dát, a co už vyhodí výjimku.

BTW tohle odvozování začne být problematické, když analyzovaná funkce bere jinou funkci jako argument nebo když chcete odvozovat generické typy.

[Bystroushaak]

Fungují dobře jen v případě, pokud je kód velmi jednoduchý nebo pokud mají speciální podporu pro použité knihovny (což platí jen pro značně rozšířené knihovny – pro ostatní knihovny máte smůlu). Například můžete zkusit napsat kód, který modifikuje nějaké třídy za běhu (třeba přidává nebo mění metody) a pozorovat, jak se s tím různá IDE vyrovnají.

S tímhle kódem si samozřejmě neporadí. Naštěstí něco takového jsem zatím nikdy nebyl nucen dělat a pokud bych byl, asi bych si našel lepší abstrakci.

Jinak řečeno, když v těch jazycích píšete jako v Javě, tak IDE fungují dobře. Když, ale začnete využívat skutečnost, že třídy jsou obyčejné hodnoty, a měnit je za běhu (čímž někdy lze ušetřit velké množství kódu), tak většina IDE selže.

Já si pořád nějak neumím představit use-case, kde bych je skutečně potřeboval měnit. Například v pythonu není problém si napsat proxy objekt, který bude odchytávat cally, což imho hodně těhle tlaků odstraňuje.

BTW tohle odvozování začne být problematické, když analyzovaná funkce bere jinou funkci jako argument nebo když chcete odvozovat generické typy.

Ano. To ale bude i s type hintingem, ne?

[Radek Miček]

Já si pořád nějak neumím představit use-case, kde bych je skutečně potřeboval měnit.

Například vygenerovat nějaký boilerplate kód? Nedělá to například SQLAlchemy? Dokumentace uvádí příklad

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    fullname = Column(String)
    password = Column(String)

a píše

Declarative replaces all the Column objects with special Python accessors known as descriptors; this is a process known as instrumentation. The “instrumented” mapped class will provide us with the means to refer to our table in a SQL context as well as to persist and load the values of columns from the database.

[Bystroushaak]

To se stále dá řešit různě.

[Radek Miček]

Ano. To ale bude i s type hintingem, ne?

Typová inference dokáže odvodit typy pro dostatečně omezený typový systém (například jako OCaml).

[Radek Miček]

Relevantní blog o přepisu 0install z Pythonu do OCamlu: Python to OCaml: Retrospective. Pokud to nechcete číst celé, vypíchnul bych zápisek OCaml: What You Gain.

[tacoberu]

Osobně v tom nevidím žádnou silnou výhodu a kdyby bylo na mě, tak bych tam tuhle featuru nepřidával, protože to kurví duck typing a původní ideu OOP, ve prospěch javovin.

Docela by mě zajímala nějaká obhajoba duck-typingu. Podle mého je to prasečina největší. Hlavní důvod, proč Python nemusím.

[kyknos]

Obhajoba? Nevim, co chces slyset, je to uzasne prakticke a jeden z duvodu, proc mi python vyhovuje

Moc nechapu tyhle vyroky typu, python by byl super, kdyby... Od toho mas jine jazyky, netreba kurvit python.

[tacoberu]

Moc nechapu tyhle vyroky typu, python by byl super, kdyby... Od toho mas jine jazyky, netreba kurvit python.

No, já zase nechápu tohle vkládání výroků, které dotyčný neřekl, a pak ho za to urážet.

[kyknos]

jiste, doslova jsi to nerekl, ale nevim, jak jinak si tve vyroky vylozit

to je jako bych prisel k nekomu se psem a zacal mu vysvetlovat, ze ma ze spa vychovat kocku

[tacoberu]

No, takhle si je vyložit opravdu nejde. Že by pokus o trolling?

[kyknos]

evidentne jde

[Bystroushaak]

Docela by mě zajímala nějaká obhajoba duck-typingu.

To je těžké. Prostě na to nemám motivaci. Za sebe můžu říct, že jsem to pochopil ve chvíli, kdy jsem se naučil základy Smalltalku, i když předtím jsem to samozřejmě pár let používal v pythonu. Prostě tak bylo OOP myšleno, předtím, než ho znásilnili a naroubovali na silně typované imperativní jazyky, s ducktypingem počítalo a byl jednou z hlavních výhod. Když došlo k chybě, tak program nespadl, ale zastavil se na debuggeru, kterým bylo možné upravit chybný kód pro všechny běžící instance a pak dál pokračovat v běhu.

[tacoberu]

Já vím, co duck-typing je a jak funguje. Proto na něj používám tak silná slova.

Pro mě je toto prostě nepřekousnutelné:

class BombTicker:
  def run(self):
    pass

class Car:
  def run(self):
    pass

def fire(a):
  a.run()

xs.append(Car())
xs.append(BombTicker())

fire(rand(xs))

[Bystroushaak]

Proč?

[tacoberu]

Run v kontextu bomby je dost něco jiného než v kontextu auta. (Ale ano, není to úplně nejšťastnější příklad na popis rozdílu semantiky. Ale spoléhám, že to chcete pochopit.)

[Bystroushaak]

No a co? Tohle značí, že je to blbě navržený model, než co jiného, když mixuje bomby s autama. Kdybys měl interface, tak maš co? Jedno ExplosiveDevice a druhé DriveableCar. Podobný efekt můžeš mít v pythonu, když pojmenuješ jednu metodu .explode() a druhou .drive().

Jinak duck typing imho začne dávat smysl hlavně ve chvíli, kdy člověk programuje alespoň trochu funkcionálně, spolu s používáním closures a list comprehensions / generator expressions.

[tacoberu]

Chápu. Takže smysl těch interfaců přesouváš do názvů těch metod, to by teoreticky mohlo fungovat.

Jinak duck typing imho začne dávat smysl hlavně ve chvíli, kdy člověk programuje alespoň trochu funkcionálně, spolu s používáním closures a list comprehensions / generator expressions.

No jako Haskellista si dovolím zásadně nesouhlasit.

Mě duck-typing nedává smysl v ničem. Jaká by měla být jeho výhoda? Zkus to prosím nějak shrnout. (Mě nenapadá žádná, ale jsem samozřejmě zaujatý.)

Teď z fleku mě napadá další nevýhoda: Chybu se dozvím nejenom až za běhu, ale až dost pozdě, až v okamžiku, kdy se runtime pokouší dobouchat na neexistující metodu, což je někde hluboko uvnitř střev, kde to vůbec neznám.

[Bystroushaak]

Chápu. Takže smysl těch interfaců přesouváš do názvů těch metod, to by teoreticky mohlo fungovat.

Já rozhodně nejsem proti interfacům. Naopak model založený na traitsech/mixinech mi přijde lepší, než vícenásobná dědičnost.

Mě duck-typing nedává smysl v ničem. Jaká by měla být jeho výhoda? Zkus to prosím nějak shrnout. (Mě nenapadá žádná, ale jsem samozřejmě zaujatý.)

V tom že kód pak může být univerzální a využívat výhod existence zapouzdření? Speciálně u metod aplikujících nějaké operace na data dodaná v sekvenci to může dávat smysl.

Chybu se dozvím nejenom až za běhu, ale až dost pozdě, až v okamžiku, kdy se runtime pokouší dobouchat na neexistující metodu, což je někde hluboko uvnitř střev, kde to vůbec neznám.

Ano. Proto je dobrým zvykem psát testy, které bys stejně musel psát tak jako tak.

[Radek Miček]

Proto je dobrým zvykem psát testy, které bys stejně musel psát tak jako tak.

BTW dobrým zvykem je také dodržovat princip DRY, což testy porušují (stejně jako typy). Lepší by bylo psát jen jedno (buď testy, nebo program, nebo typy), ideálně to, co je v daném případě nejjednodušší.

[tacoberu]

Testy jen obtížně budou pokrývat vše. Typy sice pokryjou vše, ale zase nejsou dostatečně jemné. A psát program bych volil jako poslední možnost. Bylo by lepší, když bych napsal testy, nebo typy, a nechal nějaký soft implementaci vygenerovat.

[Bystroushaak]

Testy jen obtížně budou pokrývat vše.

Proč ne? Já používám modul na coverage, který mi řekne, co mám pokryté a co ne. Obecně se nesetkávám s chybami tohohle typu, ale spíš s logickými chybami v návrhu. A od těch mi nepomůžou ani testy, ani typy.

[Radek Miček]

IMO tacoberu myslel pokrýt všechny možné vstupy – například, pokud je vstupem int32, tak otestovat cca 4 mld. hodnot (v podstatě provést model checking).

[Bystroushaak]

Tak ten coverage jede po všech větvích v kódu a chce po tobě, abys otestoval každou z nich. Je ale pravda, že to (by default) nejde na úroveň knihoven.

[radix]

Ta sama vetev kodu ti muze spadnout treba v zavislosti na tom, jestli funkce dostane jako parametr integer nebo string. Na tyhle veci je code coverage z principu nedostatecne.

Podobny problem panuje i u vetsiny staticky typovanych jazyku - vetev funguje pro vetsinu integeru, ale ne pro nulu (protoze deli nulou). I tak ti ale staticky typovany jazyk odstranuje celou tridu problemu, kterou pak nemusis zalepovat testy, ktere jsou nekompletni a predevsim overkill. Jinak jsou jazyky (s dependent typing), ktere ti dokazi pokryt i podobne problemy jako s tou nulou (ale jsou spis experimentalni jazyky).

[Bystroushaak]

Ta sama vetev kodu ti muze spadnout treba v zavislosti na tom, jestli funkce dostane jako parametr integer nebo string. Na tyhle veci je code coverage z principu nedostatecne.

Vyvolání výjimky v tomhle případě není chyba, ale žádaná vlastnost.

Podobny problem panuje i u vetsiny staticky typovanych jazyku - vetev funguje pro vetsinu integeru, ale ne pro nulu (protoze deli nulou).

Ano. Stará moudrost praví, že všechny hodnoty by se měly testovat na krajní meze datových typů a nulu. Ne vždy je to ale časově možné.

[radix]

Vyvolání výjimky v tomhle případě není chyba, ale žádaná vlastnost.

Zadana vlastnost je, aby se takto nekorektni program nedostal do produkce, resp. ani do faze manualniho testovani. Unit testy u teto tridy problemu pomuzou nekdy, staticke typovani vzdy.

Ano. Stará moudrost praví, že všechny hodnoty by se měly testovat na krajní meze datových typů a nulu. Ne vždy je to ale časově možné.

Tohle je trivialni priklad, ne vzdy jsou potencialne problematicke hodnoty na prvni pohled videt. Zrovna vcera jsem videl algoritmus, ktery selhaval na hodnotach delitelnych 100 :)

V jazyce jako Agda tohle ani testovat nemusis, protoze jazyk samotny ti nedovoli delit promennou o ktere jsi nedokazal, ze nemuze byt nulou (opet trivialni priklad, funguje to ale obecne).

[Mintaka]

Tolik potíží s tou nulou, a přitom stačilo se dohodnout, že dělení nulou je kladné nekonečno Jestli ono to dělení není celé blbě. Aspoň že si v některých jazycích můžeme nadefinovat své vlastní dělení.

Tedy pánové, diskuze zajímavá, i když by asi jen málokdo čekal co se dozví pod zprávičkou o PHP 7.0.0

Jsem zvědavý, kde bude programování za 20..40..60 let jestli už to nebude víc o AI a genetických algoritmech, které si s tím naším přehazováním dat z hromádky na hromádku poradí na úrovni strojového jazyka lépe než my.

(Kdyby to někdo nepostřehnul, tak je to pokus o dva offtopic v offtopicu.)

[kyknos]

na prednaskach z ekonomie jsem videl elegantni reseni:

mame tu ve jmenovateli nulu, ale to nevadi, misto nuly muzeme dat jednicku, to je take male cislo...

v prirodnich vedach by to nefungovalo, ale v ekonomii, astrologii a podobnych pavedach je to skutecne jedno :)

BTW ad AI: doufam ze bude zakazana :)

[Bystroushaak]

BTW ad AI: doufam ze bude zakazana :)

To imho z dlouhodobého hlediska nejde. Červená královna tě donutí jí mít a používat, neboť jinak budeš nahrazen těmi, kdo jí mají. Ať už z ekonomických, či silových důvodů. Je to stejné, jako kdyby někdo před 30 lety chtěl podnikat v oboru informací a nesnášel počítače. Tenkrát to ještě chvíli mohlo vypadat jako že to třeba snad možná půjde bez nich, ale dnes byli prostě vytlačeni a zapomenuti.

[kyknos]

no ja si spis myslim, ze kdo bude pouzivat AI, bude nahrazen tou AI... takze ti rozumnejsi budou bojovat proti AI cizi, treba z ciny

regulace AI bude mit mnohem vetsi smysl a dulezitost nez treba regulace GMO

kazdopadne, tohle bude relevantni a ve vzdalene budoucnosti, zatim je pravdepodobnejsi pilotovany let do jine hvezdne soustavy nebo fuzni elektrarna do kazde domacnosti

[Bystroushaak]

no ja si spis myslim, ze kdo bude pouzivat AI, bude nahrazen tou AI... takze ti rozumnejsi budou bojovat proti AI cizi, treba z ciny

Z čistě dlouhodobého hlediska evolučních tlaků je to imho nevyhnutelné a stejně, jako lidi nahradili třeba neandrtálce se dá s jistotou počítat, že jednou něco nahradí náš druh. Otázkou je, jestli to bude nahrazení ve smyslu vyhlazení a zaujetí místa, nebo postupného fůzování, až nebude rozdíl mezi jedním a druhým, či postupnou evolucí, kdy se třeba lidstvo plynule přejde do něčeho jiného.

[kyknos]

at tak ci onak, z naseho pohledu je potreba proti tomu bojovat

[Bystroushaak]

Z mého pohledu je nutné fůzovat.

[kyknos]

verim, ja mluvil za lidi

[Bystroushaak]

Resistance is futile.

[kyknos]

:D napodobne :)

[kyknos]

myslim, ze tohle je duvod, proc ve svetech jako je nadace pocitali hyperprostorove skoky na logaru :) se pak zakaze vsechno slozitejsi nez logaritmicke pravitko :D

[Václav "Darm" Novák]

Popřípadě Služebnický Džihád z Duny :)

[pavlix]

Tolik potíží s tou nulou, a přitom stačilo se dohodnout, že dělení nulou je kladné nekonečno

A proč ne záporné nekonečno? Myslím, že by obojí akorát udělalo hromadu bordelu a přibylo by v matematických větách pár zcela nečekaných výjimek.

[tacoberu]

Jsem zvědavý, kde bude programování za 20..40..60 let jestli už to nebude víc o AI a genetických algoritmech, které si s tím naším přehazováním dat z hromádky na hromádku poradí na úrovni strojového jazyka lépe než my.

K tomu mi právě pomocí těch typů směřujeme. Zatímco Python jde opačnou cestou.

[kyknos]

a proto je tak fajn :) (a nebude ho potreba zakazat :)

[Bystroushaak]

K tomu mi právě pomocí těch typů směřujeme. Zatímco Python jde opačnou cestou.

Ono je celkově docela zajímavé, jak moc jsou jazyky, které to přehání s typy nepoužívané. Nedávno jsem se o tom bavil s kamarádem na IRC, že jsem vlastně nikdy neviděl nic napsaného v třeba v haskellu.

Jinak já nemám nic proti typům, ani statickému typování. Imho to má svojí doménu a u některých typů software si to neumím představit bez nich. Co mi vadí jsou lidi, kteří se to snaží roubovat do pythonu.

[Jendа]

xmonad.

Mě by spíš zajímalo, jestli někdo někdy napsal něco v Prologu. Mě v tom donutili psát ve škole louskáček substituční šifry a bylo to děsivé.

[Bystroushaak]

xmonad

Neznám a nepoužívám. Popravdě jediný program, který jsem kdy v haskellu použil byla obluda a to se skoro nedá počítat, protože jsem to stáhl jen ze zvědavosti. Fakt by mě zajímalo, proč se v tom prakticky neprogramuje, když je to tady už takové desítky let. Jakože vážně, nepomlouvám - proč se v tom skoro nic nepíše?

[Radek Miček]

Třeba Facebook píše některé věci v Haskellu. Část komunity Scaly si oblíbila techniky z Haskellu.

Já osobně Haskell nepoužívám proto, že v něm nejde modulárně uvažovat o časové a prostorové složitosti.

[Radek Miček]

Hezká prezentace je Prolog and CHR in Finance.

Jinak se to používá hodně pro plánování (například některé přepravní společnosti mají v Prologu SW, který plánuje, co se má kam a čím přepravovat).

[pavlix]

Já jsem v tom psal nějaké integrály a neměl jsem nervy na to to ladit.

[Bystroushaak]

Jsem zvědavý, kde bude programování za 20..40..60 let jestli už to nebude víc o AI a genetických algoritmech, které si s tím naším přehazováním dat z hromádky na hromádku poradí na úrovni strojového jazyka lépe než my.

Všichni používáme hory abstrakce nad strojovým kódem. Jenže do vzniku generických umělých inteligencí vždy bude ten který program limitovat množství informace, kterou ho musíš popsat. I kdyby to bylo v úplně přirozeném jazyce. Ostatně programátoři dnes dělají přesně tohle - píší (různě volnou) formální specifikaci toho, co zadavatel chce. Vrstvy software pod tím z toho pak dělají funkční kód.

Jinak tuším že hned druhý MLMU talk byl o tom, jak algoritmy pěstují algoritmy, co hledají závislosti v big datech. Bohužel z toho není video, ale bylo to dost zajímavé.

[Bystroushaak]

Zadana vlastnost je, aby se takto nekorektni program nedostal do produkce, resp. ani do faze manualniho testovani. Unit testy u teto tridy problemu pomuzou nekdy, staticke typovani vzdy.

Žádaná vlastnost je, aby funkce na nedefinované vstupy reagovala výjimkou (v pythonu).

V jazyce jako Agda tohle ani testovat nemusis, protoze jazyk samotny ti nedovoli delit promennou o ktere jsi nedokazal, ze nemuze byt nulou (opet trivialni priklad, funguje to ale obecne).

Jak to funguje s uživatelskými vstupy? Jak dokážeš, že uživatel nikdy nezadá nulu, nebo že nula nikdy nebude v souboru, nepřijde po síti, ..?

[tacoberu]

Zadana vlastnost je, aby se takto nekorektni program nedostal do produkce, resp. ani do faze manualniho testovani. Unit testy u teto tridy problemu pomuzou nekdy, staticke typovani vzdy.

Žádaná vlastnost je, aby funkce na nedefinované vstupy reagovala výjimkou (v pythonu).

Na produkci?

V jazyce jako Agda tohle ani testovat nemusis, protoze jazyk samotny ti nedovoli delit promennou o ktere jsi nedokazal, ze nemuze byt nulou (opet trivialni priklad, funguje to ale obecne).

Jak to funguje s uživatelskými vstupy? Jak dokážeš, že uživatel nikdy nezadá nulu, nebo že nula nikdy nebude v souboru, nepřijde po síti, ..?

Odmítne ji, pomocí if a = 0 then .. else .. (tedy takto bych to dělal v Haskellu).

[Bystroushaak]

Na produkci?

Takhle prostě dynamické jazyky fungují a součástí práce programátora je postarat se, aby byl kód otestovaný dost na to, aby měl jistotu, že tam nikde nechtěné typy nepolezou a že aplikace umí případnou chybu zpracovat.

Odmítne ji, pomocí if a = 0 then .. else .. (tedy takto bych to dělal v Haskellu).

To ale není formální důkaz, ne?

[radix]

Soucasti prace programatora je tim padem dokazat nemozne Mimochodem, podobne praktiky vedou k psani milionu trivialnich testu, ktere se snazi nahradit chybejici staticke typovani, ale jinak nic moc netestuji.

Odmítne ji, pomocí if a = 0 then .. else .. (tedy takto bych to dělal v Haskellu).

To ale není formální důkaz, ne?

Spolu se semantikou jazyka to postacuje jako dukaz, ze a nemuze mit nikdy ve vetvi else hodnotu 0.

[Bystroushaak]

Soucasti prace programatora je tim padem dokazat nemozne

Jak to? Když programuji nějakou aplikaci, tak snad vím, co mi do ní leze, ne? Uživatel nemá možnost volit typy, jen jejich hodnoty. Tohle mi přijde jako taková ta javovská logika, kde se lidi chovají k dalším programátorům jako k nekompetentním uživatelům, přitom jsou to právě a jedině oni, kdo jediný může reagovat na chyby, ne kód knihoven, ten může jen říct, že se mu něco nelíbí. Silné typování neumožňuje nic víc, než kódu knihoven říct, že poměrně malý subset situací se mu asi možná (jen na základě předpokládaného typu!) nelíbí už během parsování.

Funkce knihoven jsou pro mě z tohohle hlediska úplně stejné, jako kdybych pracoval se vzdáleným API - prostě musím počítat, že přijímají jen něco a můžou vyhazovat výjimky, které bych měl zpracovat.

Vážně, tady se z toho dělá kdovíjaké drama, ale takhle to prostě funguje a funguje to dost spolehlivě na to, aby se to vyplatilo používat všude možně, včetně třeba velkých firem (hint: google, seznam). Dokonce se nebojím říct, že naprostá majorita webových aplikací je psaná přesně takhle a apokalypsa se nekoná. Jeden si skoro říká, jak vůbec je možné napsat řádek kódu bez silného typování, když by to mělo vést ke konci světa.

[tacoberu]

Soucasti prace programatora je tim padem dokazat nemozne

Jak to? Když programuji nějakou aplikaci, tak snad vím, co mi do ní leze, ne?

Což platí jen o write-only jazycích, což asi o Pythonu říct nechceš.

Uživatel nemá možnost volit typy, jen jejich hodnoty. Tohle mi přijde jako taková ta javovská logika, kde se lidi chovají k dalším programátorům jako k nekompetentním uživatelům, přitom jsou to právě a jedině oni, kdo jediný může reagovat na chyby, ne kód knihoven, ten může jen říct, že se mu něco nelíbí.

Ale uživatel, a programátor uživatel nějaké knihovny je opravdu v roli absolutního idiota. Protože čím více se musí s kódem seznamovat, tím je to dražší.

Silné typování neumožňuje nic víc, než kódu knihoven říct, že poměrně malý subset situací se mu asi možná (jen na základě předpokládaného typu!) nelíbí už během parsování.

Jenže v tom je ta pointa. Do čím méně stavů může funkci uživatel dostat, tím lépe se s ní pracuje. Protože prostě člověk má omezenou kapacitu pojmout celej ten graf, který to volání funkcí vytváří.

A tak vznikají boje mezi tím, aby funkce měla co nejméně stavů, a tím, aby byla co nejobecnější.

Haskell má problém IMHO až v okamžiku mutability. Proto není tak oblíbený. Python mi přijde že pro samou obecnost neposkytuje žádné záruky. Což přináší důsledky které můžou být více či méně zásadní.

[Bystroushaak]

Což platí jen o write-only jazycích, což asi o Pythonu říct nechceš.

Stejně jako bude v jiných jazycích programátor zodpovědný za to, že nemixuje typy špatným způsobem.

Ale uživatel, a programátor uživatel nějaké knihovny je opravdu v roli absolutního idiota. Protože čím více se musí s kódem seznamovat, tím je to dražší.

Proč by se měl seznamovat s kódem? Stačí mu přečíst si docstring.

Jinak tohle je asi to, kde se naše filosofie rozcházejí. Moje zkušenost mi ukázala, že v takových jazycích trávím čas věcmi, které pro samotný projekt vůbec nejsou podstatné. Má to další sympatickou vlastnost; všemožné design patterny jsou v pythonu prakticky neexistující, protože když člověk pochopí filosofii jazyka, tak je to triviální a často na jeden řádek, místo aby psal všemožné abstraktní továrny továren.

[radix]

Proč by se měl seznamovat s kódem? Stačí mu přečíst si docstring.

Tak tohle me uprimne rozesmalo. Docstringy (resp. obecne dokumentace rozhrani metod/trid) jsou velmi casto zastarale, vetsinou nekompletni (nespecifikuji ruzne corner casy) a nikdy tak exaktni jako formalni, automaticky verifikovatelny typovy kod. Lidsky jazyk neni staveny na preciznost a formalnost, coz usti v to, ze komentar je do velke miry viceznacny/nepresny.

Zkratka receno, komentare casto lzou, staticke typy ne. V praxi se na komentare metod nespoleham, ale da se z nich vycist naopak to, co formalne zapsat nejde - kontext, motivace atp.

... protože když člověk pochopí filosofii jazyka, tak je to triviální a často na jeden řádek, místo aby psal všemožné abstraktní továrny továren

Pripadne to muze byt i tim, ze clovek nechape vyznam a vhodne pouziti abstraktni tovarny.

[Bystroushaak]

Tak tohle me uprimne rozesmalo. Docstringy (resp. obecne dokumentace rozhrani metod/trid) jsou velmi casto zastarale, vetsinou nekompletni (nespecifikuji ruzne corner casy) a nikdy tak exaktni jako formalni, automaticky verifikovatelny typovy kod.

Ano, nic takového jsem ale ani netvrdil. Zastaralé můžou být asi stejně, jako všechno ostatní, od typů po samotná těla funkce.

Zkratka receno, komentare casto lzou, staticke typy ne.

Statické typy v tomhle lžou úplně stejně, jako dynamické - nezaručují, že nedojde k vyvolání výjimky v runtime při nějakém „corner case“. Tohle asi může zajistit formální verifikace, ale kolik takového kódu v praxi vzniká?

Pripadne to muze byt i tim, ze clovek nechape vyznam a vhodne pouziti abstraktni tovarny.

Když se nad tím tak zamyslím, tak je to v podstatě metodika vytvořená k boji s typovým systémem, aby se v tom daly dělat věci, které jdou dělat v dynamických jazycích úplně přirozeně.

[radix]

Zastaralé můžou být asi stejně, jako všechno ostatní, od typů po samotná těla funkce.

To mas nejake popletene - kod je vzdy "source of truth". Z principu nemuze byt zastaraly, na rozdil od komentare.

Zkratka receno, komentare casto lzou, staticke typy ne.

Statické typy v tomhle lžou úplně stejně, jako dynamické - nezaručují, že nedojde k vyvolání výjimky v runtime při nějakém „corner case“. Tohle asi může zajistit formální verifikace, ale kolik takového kódu v praxi vzniká?

To neni pravda - to, co typovy system treba Javy dokaze vyjadrit, tak v tom proste nelze. Pokud ma metoda v Jave jako navratovy typ String, tak proste nic jineho vratit nemuze. Pokud ma Python funkce v docstringu napsane, ze vraci string, tak ve skutecnosti muze vratit cokoliv.

Neco jineho je, ze expresivita typovych systemu jazyku jako C# a Java je omezena - spousta veci v nich nejde vyjadrit. To se ale zlepsuje s Haskellem, Scalou, Ceylonem az treba k Idrisu, kde je to dovedene do (obtizne pouzitelneho) extremu. Stale je to ale radove lepsi nez treba u Pythonu.

Když se nad tím tak zamyslím, tak je to v podstatě metodika vytvořená k boji s typovým systémem, aby se v tom daly dělat věci, které jdou dělat v dynamických jazycích úplně přirozeně.

[Bystroushaak]

To mas nejake popletene - kod je vzdy "source of truth". Z principu nemuze byt zastaraly, na rozdil od komentare.

To teda může. Podstatné není co je v kódu, ale jak se má program chovat podle specifikace. Když se chová jinak než je žádáno, není v kódu zdroj pravdy, ale bug. Nehledě na to, že různé části projektu můžou mít různá očekávání a pak musíš rozhodnout, které z nich je správné.

Pokud ma metoda v Jave jako navratovy typ String, tak proste nic jineho vratit nemuze.

Ehm, výjimku? Není tam taky náhodou null, který se dá vracet místo libovolných referencí? A co NaN?

Pokud ma Python funkce v docstringu napsane, ze vraci string, tak ve skutecnosti muze vratit cokoliv.

Ano, to je pravda. Je věcí cti autora, aby takové věci nedělal.

[radix]

To teda může. Podstatné není co je v kódu, ale jak se má program chovat podle specifikace. Když se chová jinak než je žádáno, není v kódu zdroj pravdy, ale bug.

Tahle otazka uz presahuje do filozofie (nominalismus/realismus) , nicmene nesouhlasim predevsim na urovni interface jednotlivych metod (o cemz se prave bavime). Mne je vcelku jedno, co dana metoda slibuje - primarne me zajima, co skutecne dela.

Ehm, výjimku? Není tam taky náhodou null, který se dá vracet místo libovolných referencí? A co NaN?

Java ma checked exceptions, interface je musi deklarovat. Unchecked exceptions se deklarovat nemusi, ale taky se *nemaji* osetrovat, takze jejich ne-deklarace moc nevadi. Jinak vyjimka se nevraci, ale haze ...

Null je zvlastni pripad, castecne je povazovany za hodnotu vsech typu (jde assignovat do vsech typu), castecne ne (null instanceof Cokoli vraci false). Nicmene tohle je blbost Javy, novejsi jazyky to maji poresene daleko lip (napr. Ceylon).

NaN je instance Double/Float, resp. hodnota primitivnich typu double/float.

Ano, to je pravda. Je věcí cti autora, aby takové věci nedělal.

To je ten obecny problem s Pythonem a podobnymi jazyky. Vsechno je na autorovi.

[Bystroushaak]

Mne je vcelku jedno, co dana metoda slibuje - primarne me zajima, co skutecne dela.

A jak ti v tomhle pomůžou typy? Pořád nemáš vůbec tušení, co metoda skutečně dělá, jen co přijímá za typ (ne data, to bys musel přidat kontrakty) a co za typ vrací.

To je ten obecny problem s Pythonem a podobnymi jazyky. Vsechno je na autorovi.

Jak jsem psal; testy ti to pomohou ověřit (pro určitý subset dat). V podstatě se na ně lze dívat jako na (neformální) verifikaci, že program v daných rozmezích dělá to co má. Teoreticky to sice nemá stejnou sílu, ale v praxi to často stačí.

[radix]

A jak ti v tomhle pomůžou typy? Pořád nemáš vůbec tušení, co metoda skutečně dělá, jen co přijímá za typ (ne data, to bys musel přidat kontrakty) a co za typ vrací.

Jak rikam, treba v Jave to neni zadna hitparada - signatura metody ti toho zas az tak moc nerekne (ale stale daleko vic nez v Pythonu). Staticke typy ti ale podobnym zpusobem pomuzou analyzovat i telo metody.

Jak jsem psal; testy ti to pomohou ověřit (pro určitý subset dat). V podstatě se na ně lze dívat jako na (neformální) verifikaci, že program v daných rozmezích dělá to co má. Teoreticky to sice nemá stejnou sílu, ale v praxi to často stačí.

To ano. Mne na tom vadi primarne to, ze je to opet na prgaci, aby ty testy napsal a maintainoval - neco, co mas v jazyce se statickymi typy zadarmo. Prgac se pak muze soustredit na psani skutecnych testu, ne jen "chytacu typovych chyb".

Nemam problem pouzit Python na nejake mensi projekty (coz obcas delam), ale nedokazu si jej moc predstavit v projektech napr. trvajicich 10 let s desitkami vyvojaru.

[Radek Miček]

Pořád nemáš vůbec tušení, co metoda skutečně dělá, jen co přijímá za typ (ne data, to bys musel přidat kontrakty) a co za typ vrací.

Typ může říci i něco o datech. Například, pokud existuje pouze jedna hodnota s daným typem.

Nebo z parametricity například plyne (v jazyce bez vedlejších efektů, kde jsou funkce totální), co dělá funkce S typu: (A -> B -> C) -> (A -> B) -> A -> C.

Jak už bylo zmíněno, existují systémy se závislými typy. Například v Idrisu jsem kdysi napsal testy takto:

test_parseLit_pos : so $ parseLit "c" == Right (MkLit Pos "c")
test_parseLit_pos = oh

Typ hodnoty oh je so True. Typová kontrola tedy musí ověřit, že typ so $ parseLit "c" == Right (MkLit Pos "c") je shodný se so True, tj. při typové kontrole se zavolá pasrseLit "c" a ověří se rovnost s Right (MkLit Pos "c"). Typ tedy říká i něco o datech funkce parseLit.

[Bystroushaak]

Ano. Teoreticky je možné opravdu všechno.

[Radek Miček]

To jsou techniky, které se používají v praxi.

[Bystroushaak]

A byl by někde seznam neakademických projektů, které jsou používány v praxi? Já do toho fakt nechci kopat, ale přijde mi to jako silně abstraktní a teoretická záležitost pro naprosté minimum computer-science nadšenců a akademiků.

[Radek Miček]

Třeba singleton typy (existuje pouze jedna hodnota s daným typem) se ve Scale používají v knihovně shapeless a tu používá řada jiných projektů. Používá se to například pro bezpečné indexování – definujeme-li

val x = ("Scala", 1)

tak x(0) resp. x(1) se přeloží jako výrazy s typy String resp. Int a x(2) se nepřeloží. Dále jsou na tom třeba postaveny kolekce s velikostí známou v době kompilace nebo rozšiřitelné záznamy (klíče jsou singleton typy – třeba řetězec title má typ String("title")).

[tacoberu]

To mas nejake popletene - kod je vzdy "source of truth". Z principu nemuze byt zastaraly, na rozdil od komentare.

To teda může. Podstatné není co je v kódu, ale jak se má program chovat podle specifikace. Když se chová jinak než je žádáno, není v kódu zdroj pravdy, ale bug. Nehledě na to, že různé části projektu můžou mít různá očekávání a pak musíš rozhodnout, které z nich je správné.

To teda nemůže. Co je v kódu typem zajištěno, na to se dá spolehnout. A pak se můžeme hádat o tom, že manžer chtěl něco jiného, než co je naprogramováno. U pythonu je to o úroveň dál. Dohaduješ se s managerem o tom, co chtěl, a co si myslíš, že je naprogramováno.

Python je o volnosti a o tom, že se spoléhá na programátory, dokumentaci, paměť. Protože na kód se v jeho případě spolehnout nedá. Věřím, že ta snadnost něco napsat je benefitem. Ale co údržba existujícího kódu? A čitelnost?

[Bystroushaak]

To teda nemůže. Co je v kódu typem zajištěno, na to se dá spolehnout. A pak se můžeme hádat o tom, že manžer chtěl něco jiného, než co je naprogramováno. U pythonu je to o úroveň dál. Dohaduješ se s managerem o tom, co chtěl, a co si myslíš, že je naprogramováno.

Manažera vůbec nebude zajímat, co je někde v kódu, ale (v lepším případě) co je ve smlouvě a hlavně jak se program skutečně chová. To jestli tam máš nebo nemáš typy bude to úplně poslední, co bude v tom sporu hrát roli.

Python je o volnosti a o tom, že se spoléhá na programátory, dokumentaci, paměť. Protože na kód se v jeho případě spolehnout nedá. Věřím, že ta snadnost něco napsat je benefitem. Ale co údržba existujícího kódu? A čitelnost?

Z mé zkušenosti plyne, že dobrá, ba řekl bych i lepší než ve většině ostatních jazyků, se kterými jsem přišel do styku, ale to může být dáno nepoměrem jak moc jsem v nich dělal a jak moc dělám v pythonu.

[tacoberu]

Uhejbáš.

[Bystroushaak]

Já už ani nevím, o čem tu diskutujeme. Mám pocit, že to začalo nějak jakože python je nahovno, protože nemá typy. Tak jsem se snažil ukázat, že není, ale skončilo to zcela dle předpovědi porovnáváním subjektivních názorů na to co je dobré, vhodné, užitečné, produktivní a co ne. Už mě to ani nebaví. Nechť si každý rozhodne sám za sebe, co mu vyhovuje a co ne.

[tacoberu]

Nevím jak ostatní.

Já nemám (subjektivně) rád duck-typing. O tom, že by byl Python nějak špatný jsem se ani náznakem nevyjadřoval. A chtěl jsem jen vědět, co je na tom duck-typingu tak užitečného, že se používá. Nic víc, nic méně.

Pak jsi se tu dost zamotal do toho, co umí a neumí typy.

Python nemá typy. To má nějaké důsledky. V praxi to možná nevadí (to mě nezajímalo), ale s těma typama sis naběhl sám.

[Mintaka]

Asi chvíli převezmu štafetový kolík :) Když se dobrá snaha, osvětlit některé mýty zvrtne, vypadají Pythonisti jako fanatici.

Re. Python nemá typy.: To je jako co za zkratku? Dokonce i typ má svůj typ "type(type)"

Programovací jazyky jsou prostředky, jak komunikovat s HW a SW počítačem. Není žádný nejlepší. Jsou jen některé méně vhodné pro konkétní nasazení a některé více vhodné. (Když jsem programoval "objektově" v Dosáckých baťácích, fakt to nebylo Hi-Fi.) Jestli má, nebo nemá jazyk silnou typovou kontrolu, je jen jedna z mnoha vlastností. Dokážu si představit mnohem propracovanější mechanismus typové a obsahové kontroly, kdy při deklaraci proměnné, nadefinuji rovnou i min / max / default / excluded hodnoty a kód hlídající, zda při každém zápisu do proměnné splňuje hodnota definované parametry.

Takovouhle nádstavbovou funkcionalitu si můžu vytvořit vlastním kódem, ale vždy to bude stát něco výkonu, při tom neustálém ověřování. Python si zvolil svoji míru kontroly a ta je nastavena tak, že si programátor může do promenné uložit "cokoliv", bez určení typu, ale nakládání s těmi hodnotami už si musí ošetřit, pokud s nimi dělá něco mimo default.

from decimal import Decimal
a = Decimal("1.15"); b = 0.555
a + b
>>> TypeError: unsupported operand type(s) for +: 'Decimal' and 'float' 
float(a) + b
>>> 1.705

Tím, že si Python zvolil takovou míru kontroly, není ani lepší, ani horší, je takový.

My lidé jsme různí (což je dobře). Vyhovuje nám různý způsob přemýšlení a komunikace s počítačem a můžeme být rádi, že tu máme různé jazyky s různými vlastnostmi.

Pár možností, jak si v Pythonu zajistit vyšší míru "typové kontrolu": * Tam kde se mi v kódu motá moc podobných názvů proměnných různých typu si některé názvy prefixuji. Například slovníky d_nazev_promenne, dvourozměrný seznam l2l_nazev_promenne, slovník seznamů d2l_nazev_promenne a pod... * Když je to v nějakém místě důležité, je možné si vyhodit debug výjimku, předat jí locals() # seznam lokálních proměnných + případně parametr, kterým určím typ kontroly a proklepnout si ty proměnné, jestli je v nich to, co tam chci mít a ve správném rozsahu. Je to hezky DRY, nezaclání to v kódu, dá se to z jednoho místa zapnout/vypnout, dá se to pustit jen pro určité, aktuálně laděné úseky. * Udělat si svůj vlastní typ s typovou (případně i obsahovou) kontrolu při každé změně hodnoty.

Pravdou je, že to na 90% věcí v podstatě není třeba.

Osvětě a práci zdar.

[Michal Kubeček]

Dokážu si představit mnohem propracovanější mechanismus typové a obsahové kontroly, kdy při deklaraci proměnné, nadefinuji rovnou i min / max / default / excluded hodnoty a kód hlídající, zda při každém zápisu do proměnné splňuje hodnota definované parametry.

Takovouhle nádstavbovou funkcionalitu si můžu vytvořit vlastním kódem, ale vždy to bude stát něco výkonu, při tom neustálém ověřování.

To je ale hodně zavádějící příklad, který se snaží vyvolat dojem, že typová kontrola je něco, co stojí prostředky. Pokud mám jazyk, kde má proměnná jasně deklarovaný typ, neznamená to, že by tato "typová kontrola" byla méně efektivní, ale přesně naopak. Kontrolu provede už překladač a za běhu je implementace výrazu a + b naopak mnohem efektivnější než kdybych měl teprve v tom okamžiku řešit, co jsou a a b zač a co tedy vlastně znamená to "+". (V případě virtuálních metod např. v C++ to bude trochu složitější, ale ani tak mne jasně deklarovaný typ nestojí nic navíc a obecně to naopak prostředky ušetří.)

[Mintaka]

Re. ...nemá typy: Myslím, že to tak asi nemyslel. Pro jistotu, že bych se pletl: http://www.diveintopython3.net/native-datatypes.html

Re. ...zavádějící příklad, který se snaží vyvolat dojem: Z mého pohledu, pokud nějaký jazyk podporuje víc než jeden datový typ, tak je tam vždy nějaká režie, která se týká typů.

A souhlasím s tím, že někdy ta režie jde na vrub překladače, někdy interpretu, někdy samotného kódu, někdy běhového prostředí či OS.

Nesouhlasím s tím, že "...jasně deklarovaný typ nestojí nic navíc".

Když vytvářím program, jsem rád, že si můžu rychle (i na mém 17 let starém počítači) spustit kód. A když je program vytvořen a stojí mi to za to, tak můžu vyrobit něco optimalizovanějšího např. .pyo nebo lépe, prohnat to nějakým optimalizátorem případně profilerem a na kritické části naprogramovat knihovnu třeba v C.

(Tím nechci říc, že by jiné jazyky neměly podobné, nebo jiné prostředky pro optimalizaci.)

[pavlix]

Z mého pohledu, pokud nějaký jazyk podporuje víc než jeden datový typ, tak je tam vždy nějaká režie, která se týká typů.

Pokud nějaký jazyk víc než jeden datový typ nepodporuje, tak je to kalkulačka nebo nějaký jednoduchý shell, podle toho, jestli je to typ číselný nebo textový. Navíc je otázka, koho ta drobná režie zajímá, když se týká například jen toho kompilátoru, to by se ta režie musela nějak vyčíslit.

[Michal Kubeček]

Nesouhlasím s tím, že "...jasně deklarovaný typ nestojí nic navíc".

Ale ono to opravdu nestojí, naopak, je to efektivnější. Když v C mám

int a, b c;

...
c = a + b

překladač hned ví, co to "+" znamená a generuje optimální kód, což většinou bude jedna instrukce, přinejhorším dvě až tři, když ty proměnné nebudou v registrech. V jakémkoli jazyce, kde bude muset program za běhu nejdřív zjistit, co jsou vlastně a, b a c zač a podle toho použít příslušnou implementaci (nebo zpracovat chybu), to vždy bude méně efektivní.

[kyknos]

pro procesor urcite, pro programatora uz mene .)

[Mintaka]

Děje se toho krapet víc. Například vám tam vzniká nová proměnná. Je třeba pro ni alokovat místo v paměti, což, pokud program nemá už dopředu zajištěno, vyžaduje komunikaci se systémem. Na základě toho, o jaký jde typ je třeba alokovat jiné místo.

V Pythonu se taková operace, aniž by se určil typ proměnných provádí takto:

#bytecode for: c = a + b
LOAD_FAST   (a)  # Pushes a reference to the local co_varnames[var_num] onto the stack
LOAD_FAST   (b)  # Pushes a reference to the local co_varnames[var_num] onto the stack
BINARY_ADD       # TOS = TOS1 + TOS
STORE_FAST  (c)  # Stores TOS into the local co_varnames[var_num]

A operace BINARY_ADD je v cpythonu takto:

#from file: cpython/Python/ceval.c
TARGET(BINARY_ADD) {
    PyObject *right = POP();
    PyObject *left = TOP();
    PyObject *sum;
    if (PyUnicode_CheckExact(left) &&
             PyUnicode_CheckExact(right)) {
        sum = unicode_concatenate(left, right, f, next_instr);
        /* unicode_concatenate consumed the ref to v */
    }
    else {
        sum = PyNumber_Add(left, right);
        Py_DECREF(left);
    }
    Py_DECREF(right);
    SET_TOP(sum);
    if (sum == NULL)
        goto error;
    DISPATCH();
}

Takže ano, je tam režie na to, že se nezná typ proměnných "a" a "b", ale ten luxus, že tím mohu sečíst cokoliv co má nadefinováno, že lze sečíst a nemusím řešit, zda zrovna pracuji s řetězci, unicode, slovníky, vlastními typy..., to mi stojí za to. Nejde o to, že bych jednou funkcí chtěl obsluhoval práci s různými typy najednou, to je spíš výjimečné, ale že se díky této vlastnosti Pythonu pohybuji v jiné vrstvě abstrakce, tak jak mi to vyhovuje.

No a pokud zrovna tuhle část potřebuji zrychlit, mám k tomu dost prostředků jak toho docílit.

[Michal Kubeček]

Děje se toho krapet víc. Například vám tam vzniká nová proměnná. Je třeba pro ni alokovat místo v paměti, což, pokud program nemá už dopředu zajištěno, vyžaduje komunikaci se systémem.

Nic takového se neděje. Zkuste si přeložit

int f(int a, int b)
{
        int c = a + b;

        return c;
}

Výsledek bude vypadat takto:

0000000000000000 <f>:
   0:   8d 04 37                lea    (%rdi,%rsi,1),%eax
   3:   c3                      retq   

Kde vidíte komunikaci se systémem? Pokud by lokálních proměnných bylo tolik, že by se do registrů nevešly, bude veškerá "alokace paměti" spočívat v jednom "sub %rsp, ..." (jednom na funkci, ne jednom na proměnnou) a přístup k nim bude jen o malinko komplikovanější. Podobně pokud by šlo o globální proměnné, bude se provádět jedna alokace při spuštění programu.

A teď si zkuste představit, jak oproti tomu bude vypadat kód odpovídající těm fragmentům, které jste napsal pro python.

[kyknos]

nejak nechapu diskusi, snazite se dokazat, ze C je rychlejsi nez Python? :D

[Michal Kubeček]

Ne, snažím se ukázat, že to, že jazyk vyžaduje, aby měla proměnná jasně deklarovaný typ, nestojí prostředky navíc, ale naopak jich hodně ušetří.

[kyknos]

_technicke_ prostredky, s lidskymi je to naopak

[Radek Miček]

To se pletete, díky typům lze naopak práci programátora ušetřit.

[kyknos]

Proto je clovek v tehle jazycich tak strasne produktivni, ve srovnani s pythonem ;)

[radix]

Presne tak.

[Radek Miček]

Ano. Techniky z dynamicky typovaných jazyků jde totiž použít i ve staticky typovaných jazycích s bohatšími typovými systémy (např. Scala a její trait Dynamic) – naopak to však neplatí.

[kyknos]

A kod bude stejne jednoduchy a zrejmy jako v tom pythonu...

[Radek Miček]

Použitím typů na vhodných místech to bude lepší než v Pythonu.

[kyknos]

co je lepsi? bude to slozitejsi, budu muset myslet na veci, ktere me nezajimaji

python je vynikajici prave ve sve primocarosti, jednoduchosti a neukecanosti - a v tom, ze ho diky tomu muze pouzivat kdokoliv, i neprogramator. proto je t bezny jazyk v ruznych ne-it oborech, treba biologii.

kdyz vidim kod treba v jave, ktery je plny ruznych hovadin jen vzdalene souvisejicich z resenim problemu, dela se mi spatne

[Bystroushaak]

Ano. Techniky z dynamicky typovaných jazyků jde totiž použít i ve staticky typovaných jazycích s bohatšími typovými systémy (např. Scala a její trait Dynamic) – naopak to však neplatí.

Proč to naopak neplatí?

[Radek Miček]

Protože nemáte statické typy.

Statické typy mohou být jemnější než tagy (dynamické typy). Například konstanta 3 může mít typ Int nebo Int @@ Zakaznik (pro id zákazníka) nebo Int(3) a chování funkcí se může měnit v závislosti na typu.

Jiným příkladem je odvozování funkcionality v době kompilace na základě typů: Součástí knihoven a vašeho programu jsou pravidla, jak z určitých funkcionalit poskládat jiné funkcionality. Když pro určitý typ kompilátor potřebuje určitou funkcionalitu, tak zkusí použít pravidla a funkcionalitu odvodit. To by šlo dělat i za běhu pomocí tagů, ale bylo by to nepraktické, neboť odvození může trvat dlouho.

[Bystroushaak]

Statické typy imho v pythonu jsou (každý objekt má typ a ten se nedá měnit), není tam statické typování (proměnné mohou ukazovat na libovolné objekty a referenci později měnit). Existují frameworky, které statické typování do jisté míry přidávají (nebo to alespoň o sobě tvrdí na homepage).

[Bystroushaak]

Ano, nějakou práci. Jinou zas přidávají. Je to něco za něco. Sice to možná ušetří nějaký subset potenciálních problémů, ale přináší to větší zátěž na programátora, který jednak poté nemůže využívat přirozenější a dynamické prvky jazyka a musí používat krkolomné způsoby obcházení (viz design patterns), ale taky musí všude psát co za typ chce a nechce a mezi nimi různě konvertovat, jen proto, že jsou typově nekompatibilní, nikoliv datově nekompatibilní.

[Mintaka]

Nejspíš si zatím nerozumíme, ale možná už jsme blízko.

Rozdělil bych mé tvrzení do dvou částí, aby to bylo lépe pochopitelné.

A. Pokud tvůrci programovacího jazyka přidávají podporu pro další datové typy, je to spojeno s nějakou režií, která se v některé fázi projeví.

B. Čím větší míru kontroly nad datovými typy případně i nad obsahem chci mít, tím větší nároky na kontrolu to vyžaduje. Opět na určité úrovni.

------ Nepolemizuji s tím, že C je pro nízkoúrovňové věci rychlejší než Python, ani s tím, že dobře udělaný program má potenciál běžet na platformách, kde půjde zkompilovat, rychleji než stejně dobře udělaný Pythonovský program. Pomíjím srovnání, kolik času který program vyžadoval.

Při práci s Int a základními datovými typy je dobře vidět, kde má C výkonnostně navrch. I ve vašem případě s intem, by bylo třeba doplnit další kód, kdybyste chtěl hlídat rozsah hodnot, které v té proměnné chcete mít. Buď při vstupu hodnoty a pak jí věřit, nebo před jejím použitím, případně na vstupu i výstupu.

Když postoupíme od Int dál,.k typům jako je např. slovník, kde klíčem i hodnotou mohou být Unicode řetězce, (pro představu, načítané z webového formuláře), dáte mi snad za pravdu, že to bude vyžadovat nějakou režii navíc, jak v C, tak v Pythonu a v jakémkoliv jazyce, který zrovna nebude všechny hodnoty proměnných převádět do jednoho datového typu. To je to co jsem myslel tím, že další datový typ a hlídání obsahu proměnných vyžaduje režii navíc.

Protože tohle už někdy někdo řešit, tak v C i v Pythonu na to použiji patřičné nástroje. V to bude nějaká šikovná knihovna, v Pythonu to budu mít k dospozici hned, ale to je jen malý nepodstatný detail.

Shodneme se na tom, že použití datového typu slovník s unicode řetězci, bude vyžadovat režii na ošetření vstupních hodnot a na práci s ním?

[Michal Kubeček]

Shodneme se na tom, že použití datového typu slovník s unicode řetězci, bude vyžadovat režii na ošetření vstupních hodnot a na práci s ním?

To ano. Problém ale vidím v tom, že pokud v případě pythonu tyhle věci budete chtít implementovat nativně v pythonu a nezadrátujete je přímo do jazyka (což je cesta, kterou se na začátku vydalo PHP), bude ta režie pořád podstatně větší - právě proto, že ty elementární operace budou oproti programu napsanému v C podstatně méně efektivní. Totéž platí i pro ty ostatní příklady, jako je kontrola mezí.

Proto bych pro takové účely daleko raději použil C++, u kterého můžu příslušnou knihovnu napsat přímo v něm a získat jak pohodlnost vyjadřovacích prostředků, tak efektivitu velmi blízkou implementaci v C. (Tedy kdybych to opravdu potřeboval psát sám a nešlo využít už hotových součástí standardní C++ knihovny.)

[tacoberu]

Takže ano, je tam režie na to, že se nezná typ proměnných "a" a "b", ale ten luxus, že tím mohu sečíst cokoliv co má nadefinováno, že lze sečíst a nemusím řešit, zda zrovna pracuji s řetězci, unicode, slovníky, vlastními typy..., to mi stojí za to.

Nechcete doufám trvrdit, že toto v staticky typovaných jazycích nelze, že ne?

Proč mám dojem, že tu Pythonisti vymýšlení problémy, které nejsou. Proč prostě nemůžete jednoduše a jasně vysvětlit proč Python nepoužívá statickou typovou kontrolu? V čem duck-typing přináší výhodu?

Beru jako odpověď i: "prostě proto", případně "nebaví nás psát typové deklarace raději to zapíšem do testů".

A abych byl (na rozdíl od místních) poctivý, tak zatím se mi z Bystroushaáka podařilo vymlátit dvě výhody: 1. kratší zápis 2. je zde jistá šance, že se autor trefí do názvu metody, a nebudu muset dělat přemapování.

Co dál?

[alza]

Je to proste mnohem rychlejsi a jednodussi. Pisu jen to, co je nutne psat. Proto napisu totez desetkrat rychleji. Nemusim premyslet, zda funkci davam seznam, tuple atd. Kdyz sectu dva kladne inty, nemuze se mi stat, ze dostanu zaporne cislo, jako treba v cecku (nikdy jsem nepochopil, jak to vubec nekdo muze takto pouzivat a resit, zda mu to nahodou nepretece, to bych nedelal nic jineho).

[Radek Miček]

Nemusim premyslet, zda funkci davam seznam, tuple atd.

Pokud je například v té funkci x + [2] a vy jako x předáte tuple, tak se to bude chovat jinak, než když předáte seznam. Takže to řešit musíte.

nikdy jsem nepochopil, jak to vubec nekdo muze takto pouzivat a resit, zda mu to nahodou nepretece, to bych nedelal nic jineho

Někdy je modulární aritmetika užitečná. Nicméně bych ji rovněž nedával jako defaultní.

[kyknos]

Pokud je například v té funkci x + [2] a vy jako x předáte tuple, tak se to bude chovat jinak, než když předáte seznam. Takže to řešit musíte.

kdyby byly v prdeli ryby... vetsinou nic takoveho ve funkcich nemam a pokud budu z nejakeho duvodu mit, tak to holt resit budu muset. ale v 99%+ pripadu to resit nemusim. stejne tak funkce ze standardni knihovny a vetsiny dalsich knihoven, co bezne pouzivam

Někdy je modulární aritmetika užitečná. Nicméně bych ji rovněž nedával jako defaultní.

v podstate me nenapada pripad, kdy bych si byl jisty, ze mi int32 nebo 64 staci - predpokladam, ze je na to v c a spol nejaka knihovna, ale ve vysledku by to znamenalo, ze bych bezne ceckove scitani intu nikdy nepouzil

[tacoberu]

vetsinou nic takoveho ve funkcich nemam

No vidiš to. V mém případě je něco takového dobře dvě chyby z pěti.

[kyknos]

a co ja s tim?

1) bud python neumis pouzivat

2) nebo v nem delas neco, na co se nehodi

ani jedno se netyka meho pythonu

[tacoberu]

Nemohl by si se vrátit zpět k tématu?

[tacoberu]

Je to proste mnohem rychlejsi a jednodussi. Pisu jen to, co je nutne psat. Proto napisu totez desetkrat rychleji.

A to je tedy všechno, jo? Já jen pro pořádek.

Nemusim premyslet, zda funkci davam seznam, tuple atd.

Ano, to jsem psal. To já v haskellu, v javě, v c# taky ne. A co?

Kdyz sectu dva kladne inty, nemuze se mi stat, ze dostanu zaporne cislo, jako treba v cecku (nikdy jsem nepochopil, jak to vubec nekdo muze takto pouzivat a resit, zda mu to nahodou nepretece, to bych nedelal nic jineho).

Tak porovnávat to zrovna s typy v céčku je docela sprostý, ti povim. To si moc nezafrajeřil. Když sečtu dva inty v Haskellu tak se mi taky nestane, že bych dostal záporné číslo.

[kyknos]

tak plest do toho haskell, coz je jazyk na domaci ulohy na matfyzu, v praxi v podstate nepouzitelny (protoze ho skoro nikdo nepouziva)...

ale je mi to jedno, at si kazdy pouziva, co chce - a jiste by byla blbost psat kernel nebo vykonnou 3D aplikaci v pythonu. ale pro me ucely je python nejlepsi a zrejme neprekonatelna volba. a pokud se objevi neco lepsiho, bude to jen zdokonaleni pythonovskeho pristupu. protoze ten mi proste naprosto vyhovuje.

a ze bych chtel python nahradit dinosaurem typu java, to bych se musel hodne uhodit do hlavy

[tacoberu]

Nemohl by si se vrátit zpět k tématu?

[kyknos]

vzhledem k tomu, ze neni jasne o co ti jde, tak asi ne .)

[tacoberu]

Jasný. Já to tu nepsal dvakrát, co?

[kyknos]

nedava to smysl

[tacoberu]

Dotaz, jaké má duck-typing výhody - nedává smysl? Tak fajn.

[kyknos]

na to uz ti bylo xkrat odpovezeno :)

[tacoberu]

Což samozřejmě kecáš, že jo :-P

[tacoberu]

Dobře, tak něco jednodužšího. K čemu má Python typy?

[Bystroushaak]

Jak by to mělo fungovat bez nich?

[tacoberu]

Stejně?

[Bystroushaak]

Vysvětli.

[tacoberu]

Myslím, že stejnou myšlenkou se zabíváme tady.

[kyknos]

pokud to bude fungovat stejne (tedy stejny kod bude mit stejne chovani), ale nekde hluboko uvnitr bude neco jinak, co te filosoficky uspokoji, tak je mi to vcelku jedno, jen tedy nechapu, proc to resis :)

[tacoberu]

Já to neřeším. Učím se. Jakmile člověk přestanu zkoumat nové věci a způsoby, a jak to dělat lépe, končí.

[tacoberu]

Asi chvíli převezmu štafetový kolík :) Když se dobrá snaha, osvětlit některé mýty zvrtne, vypadají Pythonisti jako fanatici.

Re. Python nemá typy.: To je jako co za zkratku? Dokonce i typ má svůj typ "type(type)"

A k čemu ten Python ty typy vlastně má?

[Bystroushaak]

Python nemá typy. To má nějaké důsledky. V praxi to možná nevadí (to mě nezajímalo), ale s těma typama sis naběhl sám.

Python právě má typy. Je to silně typovaný jazyky a úplně všechno v něm má typ, který se po vytvoření nikdy nedá změnit (narozdíl od třeba javascriptu). Proměnné jsou ovšem jen reference na tyhle objekty a jako takové můžou ukazovat na objekty libovolných typů a reference později měnit.

[Radek Miček]

Kdyby se to bralo trochu formálněji, tak ne. Resp. šlo by říci, že má jeden typ.

[pavlix]

Python nemá typy.

Hmm, tak to asi píšu v něčem jiném, dík za poučení.

[Radek Miček]

V Pythonu se říká typy něčemu, co matematici nebo informatici za typy nepovažují. Viz třeba Does “untyped” also mean “dynamically typed” in the academic CS world? – cituji Andrease Rossberga:

To understand it, it helps to know that the notion of "type" was invented in the 1930s, in the context of lambda calculus (in fact, even earlier, in the context of set theory). Since then, a whole branch of computational logic has emerged that is known as "type theory". Programming language theory is based on these foundations. And in all these mathematical contexts, "type" has a particular, well-established meaning.

The terminology "dynamic typing" was invented much later -- and it is a contradiction in terms in the face of the common mathematical use of the word "type".

For example, here is the definition of "type system" that Benjamin Pierce uses in his standard text book Types and Programming Languages:

A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.

He also remarks:

The word “static” is sometimes added explicitly--we speak of a “statically typed programming language,” for example--to distinguish the sorts of compile-time analyses we are considering here from the dynamic or latent typing found in languages such as Scheme (Sussman and Steele, 1975; Kelsey, Clinger, and Rees, 1998; Dybvig, 1996), where run-time type tags are used to distinguish different kinds of structures in the heap. Terms like “dynamically typed” are arguably misnomers and should probably be replaced by “dynamically checked,” but the usage is standard.

Most people working in the field seem to be sharing this point of view.

[Bystroushaak]

To je tedy fakt hodně diskutabilní. V pythonu jsou imho úplně stejné typy, jako všude jinde, ale nejsou vázané na proměnnou, ale k objektům. Pokud by někdo chtěl, nebyl by problém napsat preprocesor, který by se choval k celému pythonu jako ke staticky typovanému (ostatně mám takový pocit, že rpython tohle dělá), protože celý jazyk je silně typovaný.

Python je v tomhle odlišný třeba od javascriptu, který není silně typovaný, ani staticky typovaný a naroubovat tam typování by šlo jen docela těžce.

[Radek Miček]

V pythonu jsou imho úplně stejné typy, jako všude jinde, ale nejsou vázané na proměnnou, ale k objektům.

Což je právě úplně jiné. Ve staticky typovaných jazycích je typ v podstatě jen výrok o nějakém výrazu (například po vyhodnocení vyjde celé číslo; nebo výraz jde vyhodnotit ve dvou krocích – což je třeba užitečné, když pomocí typového systému chcete kontrolovat časovou složitost). Zatímco v Pythonu je to jakýsi tag, který je součástí hodnot (nikoliv výrazů).

Java má třeba oboje. Typ může být například List<String> a odpovídající tag jen List (protože tagy v Javě neumí reprezentovat generika). Ale obecně mezi typem a tagem nemusí být žádný vztah.

Typy ve staticky typovaných jazycích přiřazují nějaká pravidla odvozovacího systému a tato pravidla často dovolují přiřadit i nekonečně mnoho typů naráz. Například hodnota pes může mít typy Pes i Zvíře i Object zatímco tag bude vždy Pes.

[deda.jabko]

Ve staticky typovaných jazycích je typ v podstatě jen výrok o nějakém výrazu (například po vyhodnocení vyjde celé číslo; nebo výraz jde vyhodnotit ve dvou krocích – což je třeba užitečné, když pomocí typového systému chcete kontrolovat časovou složitost).

Prisne vzato oba dva mluvite trochu o necem jinem, proto si IMHO nemuzete rozumet. Ty evidentne chapes "typ" vcetne "typoveho systemu". Bystroushak IMHO chape typ jako pouhe "pojmenovani" pro "mnozinu hodnot", z ktere dana hodnota pochazi... a staci mu to.

[pavlix]

Takže třeba integer nebo string nejsou informatiky považovány za typy?

[Radek Miček]

Ne. Podstata je, že se jedná o statickou klasifikaci termů programu – tj. části programu klasifikujete před jeho spuštěním. Ideálně vám pak tato klasifikace dá určitou informaci, jak se program bude chovat za běhu. Python žádnou takovou klasifikaci před spuštěním programu neprovádí.

[Mintaka]

A není v Pythonu ta klasifikace obsažena, jen na jiné úrovni, v tom, že objekt typu int má v Pythonu dávno před spuštění programu definovány metody:

a = 1; type(a) 
>>> <type 'int'>
dir(a) 
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__', '__delattr__', 
'__div__', '__divmod__', '__doc__', '__float__', '__floordiv__', '__format__', 
'__getattribute__', '__getnewargs__', '__hash__', '__hex__', '__index__', '__init__',
 '__int__', '__invert__', '__long__', '__lshift__', '__mod__', '__mul__', '__neg__', 
'__new__', '__nonzero__', '__oct__', '__or__', '__pos__', '__pow__', '__radd__',
 '__rand__', '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__',
 '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__', '__rpow__',
 '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__', '__rxor__', '__setattr__', 
'__sizeof__', '__str__', '__sub__', '__subclasshook__', '__truediv__', '__trunc__', 
'__xor__', 'bit_length', 'conjugate', 'denominator', 'imag', 'numerator', 'real']

b = "1"; type(b)
>>> <type 'str'>
dir(b) 
['__add__', '__class__', '__contains__', '__delattr__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__getitem__', '__getnewargs__', 
'__getslice__', '__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__',
 '__mod__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__',
 '__repr__', '__rmod__', '__rmul__', '__setattr__', '__sizeof__', '__str__', 
'__subclasshook__', '_formatter_field_name_split', '_formatter_parser', 
'capitalize', 'center', 'count', 'decode', 'encode', 'endswith', 'expandtabs',
 'find', 'format', 'index', 'isalnum', 'isalpha', 'isdigit', 'islower', 'isspace',
 'istitle', 'isupper', 'join', 'ljust', 'lower', 'lstrip', 'partition', 'replace',
 'rfind', 'rindex', 'rjust', 'rpartition', 'rsplit', 'rstrip', 'split', 'splitlines', 
'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill']

?

[tacoberu]

Ale v takovém případě ten typ je jen taková nálepka, a k ničemu praktickému to není. Prostě stačí, když udělám obecný objekt, a pak mu přidám všechny ty metody, co má int a vznikne mi int, správně? To je ostatně princip duck-typingu.

[kyknos]

je trosku rozdil mezi intem a floatem, napriklad, ze? nebo ti proste nerozumim. zkus se vyjadrit, o co ti vlastne jde. a co tu resis. porad to na me pusobi dojmem, ze ty chces nam nutit, ze mame pouzivat neco jineho. protoze tobe tvou javu nebo co pouzivas nikdo nebere. rad si cvicis prsty? pis hello world treba v ooku, je mi to jedno. ale mne vyhovuje python takovy, jaky je. a to vcetne zachazeni s typy. teoreticka vysvetleni ti k tomu davat nebudu, protoze je neznam a nezajimaji me. nejsem teoreticky informatik, pouzivam python jako nastroj. a mozna proto mi vyhovuje.

[tacoberu]

Hele, to nemá cenu. Už jsem to tu psal několikrát. Já vám Python neberu. A jestli budeš pokračovat ve svém fantazírování, a vymejšlet si, tak to můžem rovnou zabalit. Ani na jednu mou otázku si neodpověděl, jen si vymýšlíš obvinění. To mě neba.

[Bystroushaak]

Ale v takovém případě ten typ je jen taková nálepka, a k ničemu praktickému to není. Prostě stačí, když udělám obecný objekt, a pak mu přidám všechny ty metody, co má int a vznikne mi int, správně? To je ostatně princip duck-typingu.

Špatně. Nevznikne ti int, vznikne ti něco, co se chová jako int a všechny funkce s tím mohou pracovat jako s intem, ale int to není. Jsou jazyky, které typy vůbec nemají (třeba self, kde je všechno prototype-based), kde by se takový kód dal považovat za int, python to ale není. Imho je to dané tím, že používá class-based OOP, které si bez typů neumím představit.

[tacoberu]

Co je na tom špatně?

Chová se to jako int, všechny funkce s ním budou pracovat jako s intem, tak to stačí, ne? Co chtít víc?

Všimni si prosím na co se ptám. Pokud má Python duck-typing, k čemu má typy? K čemu jsou dobré?

[kyknos]

kdyz se to chova jako int, tak je to int, ne? kdyz se to chova jako float, tak je to float.

[tacoberu]

Taky si myslím.

[kyknos]

a co z toho vyplyva?

[tacoberu]

K čemu tedy má Python typy, když je zdá se nepotřebuje.

[kyknos]

imho potrebuje

nebo nechapu, cemu rikas, nemit typy

ja bych rekl, ze je docela podstatne rozlisit, zda je dana hodnota float, int nebo treba string

[kyknos]

nebo jeste lepe 0.1 float versus decimal

[tacoberu]

Mluvíš mi z duše. Ale v Pythonu, krom věcí jako isinstance() a type() je to prakticky nevyužité.

[kyknos]

nerozumim

ja potrebuji mit pod kontrolou, zda je ma hodnota float nebo decimal

vyuzivam to neustale

pod tvym "nemit typy" si predstavuju, ze si vsechna cisla budou rovny, jako to je tusim v javascriptu - to bych ten python hodil z okna

[tacoberu]

pod tvym "nemit typy" si predstavuju, ze si vsechna cisla budou rovny

Ne, oni si nebudou rovny, protože int je struktura implementující __int__, zatímco float je struktura implementující __float__ (zjednodušuji, přirozeně).

vyuzivam to neustale

Jak to tvoje využívám to neustále v praxi funguje? Pomocí funkcí type() a isinstance() ?

[kyknos]

nevim, cemu rikas typ a cemu struktura :) a je mi to jedno

proste nekdy potrebuju pocitat s floaty, nekdy s inty a nekdy s decimaly

to jsou imho typy... jestli tomu budes rikat struktury, je mi zcela volne - hlavne, ze to funguje tak, jak to funguje

>>> a = Decimal(1)/10
>>> b = 1/10
>>> a == b
False
>>> type(a)
<class 'decimal.Decimal'>
>>> type(b)
<class 'float'>
>>>

jestli te nechapu, zkus to vice polopaticky, jsem jen biolog, a navic jsem blond :)

[Bystroushaak]

Všimni si prosím na co se ptám. Pokud má Python duck-typing, k čemu má typy? K čemu jsou dobré?

Jsi trol, nebo jen nečteš co píšu?

[tacoberu]

Čtu. A velice pečlivě, jak jsi si mohl všimnout, při mém uvádění věcí na pravou míru u některých tvých tvrzení.

Tak mi to tu zkus ocitovat, a zdůraznit, co považuješ za to vysvětlení. Já to v tom opravdu a poctivě vůbec nevidím.

[Bystroushaak]

Imho je to dané tím, že používá class-based OOP, které si bez typů neumím představit.

[tacoberu]

Supr. A když vyhodíš ten buzzword balast?

Vysvětli mi posím v čem vidíš souvislost mezi class-based OOP a tím, že třída plně se chovající jako int ve skutečnosti intem není?

Pokud je pro tebe typ synonymem pro vytváření tříd, tak si představ funkci, která vytvoří strukturu s funkcema, která dohromady dává int. Tato funkce reprezentuje tu třídu. Takto se v javascriptu simuluje class-based OOP, když někdo nechce používat prototypy. V lue je to hodně podobné.

Ono to tak dokonce v pythonu přesně takhle je. Máš tam funkci, která vytváří třídu, a funkci, která je atributem té třídy, která vytváří instanci.

[Bystroushaak]

Vysvětli mi posím v čem vidíš souvislost mezi class-based OOP a tím, že třída plně se chovající jako int ve skutečnosti intem není?

Protože není ve stromu tříd pod intem? Nemá dědičnost? Když změním za běhu definici intu, tak se nezmění, protože na něj není nijak navázaná?

[tacoberu]

No hurá, už se k něčemu dostáváme.

Ty opravdu za běhu měníš chování existujících tříd? MonkeyPatching? Měl jsem za to, že to jde jen u Ruby, a Python toto nedělá. Můžeš za běhu změnit definici třídy, ale již vytvořené instance mají původní chování. Zkusil jsem, a teda, je to pro mě novinka.

No, každopádně už chápu, co si pod tím typem představuješ. Díky za vysvětlení.

[pavlix]

Pythoní objekty se pokud vím na třídu odkazují, takže její změny musejí mít vliv na chování.

[tacoberu]

Že to tak je, fajn. Ale že je to udělané jen kůli MonkeyPatchingu... Koukám, Python stále umí nepříjemně překvapit.

[Bystroushaak]

Ale že je to udělané jen kůli MonkeyPatchingu...

No, a takhle vznikají pověry.

[tacoberu]

Tak to nebude pověra, že jo, když to nedokážeš vysvětlit.

Závěry, které jsem si z téhle nekonečné a nespolupracující diskuse vzal:

1. Duck-typing je použit proto, protože je úspornější na použití, tudíž zvyšuje čitelnost. I za cenu toho, že může dojít k sématické chybě. Protože je to ale velice malá pravděpodobnost takové chyby, tak to autoři akceptovali, jako přijatelené riziko.

2. Typy jsou použity jako syntax-suggar pro tovární funkce. A protože je požadován MonkeyPatching, tak taková implementace není triviální. (Doporučuj mrknout, jak se dělají konstruktory v objective-c, velice inspirativní.)

3. Jinak jsou typy použity jako značky (atribut {}.__class__), značky vytvářejí strom, dá se na ně dotazovat, ale žádný další význam nemaj.

4. A trochu hejt: díky pythonu mají někteří lidé velice zkreslené představy, co to je typování, a statická typová kontrola zvláště.

[Bystroushaak]

Tak to nebude pověra, že jo, když to nedokážeš vysvětlit.

Tak já jsem snad tvůrce jazyka, nebo proč bych měl mít vysvětlení na otázky typu „a proč?“? Problém s předchozím tvrzením mám, že jsi z toho udělal jediný důvod. Je to prostě jen jeden z mnoha.

3. Jinak jsou typy použity jako značky (atribut {}.__class__), značky vytvářejí strom, dá se na ně dotazovat, ale žádný další význam nemaj.

A co dědičnost? Polymorfizmus? Statické proměnné a vůbec celé class-based OOP?

4. A trochu hejt: díky pythonu mají někteří lidé velice zkreslené představy, co to je typování, a statická typová kontrola zvláště.

Já bych řekl, že mám docela dobrou představu o tom co jsou a jak fungují běžné statické typové systémy, asi tak na úroveň, že bych dokázal vytvořit kompilátor pro takový jazyk. Tuhle diskuzi jsem ale vedl se třemi lidmi najednou a bylo krapet těžké udržet focus vlákna pro každého zvlášť a ještě při tom vysvětlovat/obhajovat python a jeho typový systém.

Diskuze pro mě ale byla i tak přínosná, i když stále vůbec nejsem přesvědčen, že statické typování nějak zvyšuje produktivitu. Stále se domnívám na základě vlastních zkušeností, že je to přesně naopak, rozhodně co se týče produktivity ve smyslu rychlosti vytvoření programu (=psaní kódu a vymýšlení architektury).

S čím souhlasím je, že typy redukují určitý druh chyb, nikoliv však chyby všechny. U kritického software (nemocnice, řídící systémy letadel a tak dále) si to taky nedokáži představit v čistém pythonu a určitě bych tam buď chtěl statické typování, nebo úplně jinou architekturu (posílání zpráv, formální verifikace, nebo něco úplně jiného).

[tacoberu]

Tak to nebude pověra, že jo, když to nedokážeš vysvětlit.

Tak já jsem snad tvůrce jazyka, nebo proč bych měl mít vysvětlení na otázky typu „a proč?“? Problém s předchozím tvrzením mám, že jsi z toho udělal jediný důvod. Je to prostě jen jeden z mnoha.

Žádný další důvod se mi z vás nedaří vymlátit. Takže to vypadá, že není.

3. Jinak jsou typy použity jako značky (atribut {}.__class__), značky vytvářejí strom, dá se na ně dotazovat, ale žádný další význam nemaj.

A co dědičnost? Polymorfizmus? Statické proměnné a vůbec celé class-based OOP?

No, co s tím? K tomu typy nepotřebuješ.

Ale aby zase někdo nenabyl dojmu, že jsem vůči Pythonu nějak zaujatý: Python má dva obrovské benefity:

1. Je extrémně dynamický (to, že i třída je first-class object je naprosto fantastické). 2. Syntax suggar a s tím související dobře navržené názvosloví, způsoby použití etc.

Jsou jazyky, které jsou mnohem čistěji navržené při zachování stejné dynamičnosti (Lua), nebo mají lepší práci s typy, třídami, a rozhraními (třeba PHP), nebo jsou bezpečnější a znovupožitelnější (Java). V ničem z toho Python nijak neexceluje. V čem je naopak naprosto perfektní je dynamičnost a čitelnost zkloubená dohromady.

[kyknos]

hura, konecne si prisel na to, ze na ruzne veci se hodi ruzne jazyky

python neni ada

python je v mnoha vyznamnych oblastech tim nejlepsim co existuje - netreba ho kurvit pro to, aby ti vyhovoval lepe v jine oblasti - to je stejna blbost jako na osobni auto pridelavat kridla, aby take mohlo letat

[tacoberu]

Škoda, že ty jsi stále nepřišel na to, že to tvé obviňování je jen tvá fantazie.

[kyknos]

zkus si nekdy po sobe precist, co pises

[tacoberu]

Hmm, to by mě docela zajímalo, co bych měl zjistit. Chápej, tvou fantazii nemám, takže mi to možná rovnou prozraď. Ať se zbytečně netrápím hledáním nějaké logiky či dokonce souvislostí.

[Bystroushaak]

Žádný další důvod se mi z vás nedaří vymlátit. Takže to vypadá, že není.

To je jako přijít na poštu a chtít po nich jízdenku na vlak, a když ti jí neprodají, tak usoudit, že vlaky neexistují.

No, co s tím? K tomu typy nepotřebuješ.

Nepotřebuješ v tom smyslu, že když je nebudeš mít přímo v jazyce, tak je musíš emulovat knihovnou (protože skáčeš k závěrům, tak radši zdůrazňuji: tohle nic neříká o tom, že se nemůžeš vzdát class-based OOP a fungovat úplně bez typů).

[tacoberu]

To přirovnání neberu.

Hele, když mě budeš pozorněji sledovat: Já jen rozpitvávám, k čemu v Pythonu ty typy slouží.

Nemusím se vzdávat class-based OOP a fungovat úplně bez typů.

Prostě nesouhlasím s tvejma tvrzeníma - je to hřích? Některé tvé argumentace mi přijdou nekonzistentní, tak hledám, v čem je problém - vadí to hodně?

Akceptoval jsem, že ty si pod typy něco představuješ, a pokusil se naladit na tvojí vlnu. Nechceš to taky zkusit? :-P

[Bystroushaak]

Prostě nesouhlasím s tvejma tvrzeníma - je to hřích?

Hřích? Co jsme, náboženský kroužek?

Akceptoval jsem, že ty si pod typy něco představuješ, a pokusil se naladit na tvojí vlnu. Nechceš to taky zkusit? :-P

Na internetu bývá zvykem při nesouhlasu argumentovat. To jsem udělal, nedošlo k tomu ale z tvé strany. Když něco říkáš, říkáš to jako obecně platné tvrzení, nikoliv podmíněné tvrzení (to musíš napsat "imho", "afaik", "já si myslím" a ideálně i proč), či argumenty podložený názor (to musíš uvést ty argumenty). Nevadí mi to v principu, ale vadí mi to, když diskutuješ se mnou. Například teď pořád tvrdíš, že k class-based OOP nepotřebuješ typy, nijak to nedokládáš argumenty a požaduješ po mě, abych .. co vlastně?

To přirovnání neberu.

Na tom není co brát. Python tu nikdo z nás nevymyslel, ani nenavrhl, všechny informace o jeho typovém systému jsou z naší strany jen domněnky, či zprostředkované dojmy. Pokud chceš skutečně vědět proč (což je tvá původní otázka), napiš autorovi, je stále naživu, těší se dobrému zdraví a odpovídá na emaily. Nikdo z téhle diskuze nebude nikdy relevantním zdrojem informací na otázky typu „proč to tak je“, protože nikdo z nás u toho nebyl. Těžko můžeš z naší neochoty spekulovat o otázkách „proč to tak je“ vyvozovat důvody, proč to tak skutečně je, protože to spolu vůbec nesouvisí - tímhle způsobem můžeš odvodit libovolnou (nesmyslnou) teorii.

[tacoberu]

Akceptoval jsem, že ty si pod typy něco představuješ, a pokusil se naladit na tvojí vlnu. Nechceš to taky zkusit? :-P

Na internetu bývá zvykem při nesouhlasu argumentovat. To jsem udělal, nedošlo k tomu ale z tvé strany. Když něco říkáš, říkáš to jako obecně platné tvrzení, nikoliv podmíněné tvrzení (to musíš napsat "imho", "afaik", "já si myslím" a ideálně i proč), či argumenty podložený názor (to musíš uvést ty argumenty). Nevadí mi to v principu, ale vadí mi to, když diskutuješ se mnou. Například teď pořád tvrdíš, že k class-based OOP nepotřebuješ typy, nijak to nedokládáš argumenty a požaduješ po mě, abych .. co vlastně?

Napadlo tě někdy, že si myslím přesně to samé já o tobě? Já předkládám argumenty všude, tvé nějak moc nevidím, a když náhodou ano, a když jsou poněkud zavádějící a já tě na to upozorním, tak se začneš rozčilovat...

Samozřejmě je všechno IMHO, a AFAIK, a "Já si myslím". Jsme v nějakým babinci, že slušní na sebe být nemusíme, ale tahat za slovíčka je dobrým zvykem?

Ty tvrdíš, že "Problém s předchozím tvrzením mám, že jsi z toho udělal jediný důvod. Je to prostě jen jeden z mnoha." a když se tě tedy zeptáš na ty další důvody, tak ticho... a vysmíváš se mi přirovnáním s poštou. A nakonec tady šermuješ prohlášením, že na internetu je zvykem argumentovat.

Myslím, že na takovouhle argumentaci fakt nejsem zvědavej.

[Bystroushaak]

Příloha:

• How-to-Learn-Emacs8.jpg (1009479 bytů)

Abys z toho nevyšel úplně s pocitem křivdy, tady máš recept na psí sušenku a v příloze cheatsheat na emacs.

[tacoberu]

V poho. Se s váma trollama musím naučit pracovat

[pavlix]

A trochu hejt: díky pythonu mají někteří lidé velice zkreslené představy, co to je typování, a statická typová kontrola zvláště.

Jak může Python zkreslit představy o statické typové kontrole, to je mi záhadou.

[Mintaka]

Tak to vidíš lyšáku. Pár postů a nakonec přišlo "snad i" porozumnění. Ani to moc nebolelo :)

Možná se blýská na lepší časy. Když už máme i ten interpret Pythonu v JavaScriptu. http://www.brython.info

Takže teď zase zpátky ke svému kódu, ať to frčí :) a lovu zdar

[Mintaka]

...a ještě by mě zajímalo, proč píšu lišáku s tvrdým "y"...

[Bystroushaak]

Možná se blýská na lepší časy. Když už máme i ten interpret Pythonu v JavaScriptu. http://www.brython.info

Ten máme už dlouho, psal jsem tu o něm blog už v roce 2013. Jinak mimochodem ho teď používám v jedné zakázce.

[freshmouse]

Těžko hledat čitelnější jazyk než Python, že.

[radix]

Python je krasne citelny na urovni par desitek radku v par metodach. Ne ve velkych projektech.

[Bystroushaak]

Dělal jsi někdy na „velkém projektu“ v pythonu? Nech mě hádat: ne?

Já právě dělám na řekněme „středním“ projektu, který má podle výstupu z cloc (bez komentářů, bez knihoven, prázdných řádků a tak dále) desítky tisíc řádek. Čitelné / orientovatelné je to imho pořád velmi dobře, díky modularizaci na jednotlivé komponenty.

Seznam a Google patří mezi velké firmy, které python interně masivně používají. Ze seznamu znám pár lidí, mimo jiné právě python programátora, který tam udržoval interní projekty o velikosti statisíců řádků. I když tam občas byly dost divné kusy kódu psané někdy v devadesátých letech někým pod silným časovým tlakem, tak celkově se v tom podle toho co psal vyznat dalo docela normálně.

Takže tak.

[radix]

Delal jsem na velkych projektech v PHP. Veci, ktere me sraly byly spolecne s Pythonem - nemoznost spolehlive zjistit, co funkce vola a co ji vola, co dostava za argumenty a co ma vracet, minimalni zapouzdreni (teda v PHP5 se to zlepsilo, v Pythonu AFAIK ne), nasledna mizernost toolu na refaktoring a statickou analyzu atp.

Spousta veci by se dala vyresit - napriklad pokud by byli programatori dokonali a psali ke vsemu vycerpavajici kontrakty (a pak je neporusovali). Ale vis co, programatori dokonali nejsou - dokumentace kontraktu je mizerna, zastarala nebo neexistujici a ty je ani nemuzes nakopat do prdele, protoze tam uz 5 let nepracuji.

Programatori v Jave, C# atp. jsou taky prasata. Zrovna ted se zkousim dostat do C# projektu, jehoz ruzne komponenty maji celkem asi 1 mega radku. Je to neskutecny bordel, horsi kod jsem asi v praxi nevidel. Typy a ruzne zapouzdrovaci ficury (assembly internal) ti ale poskytuji aspon nejake pevne body, kterych se muzes ty (a tvoje tooly) chytit.

[Bystroushaak]

Aha, hm. Soudit python a programování v něm podle php, to pak jo.

[radix]

Lisi se snad PHP od Pythonu ve vecech, ktere zminuju?

[Mintaka]

Rohy i nohy má stůl i vůl. Oba je možné zvážit a v některých případech mohou vážit úplně stejně. Dokonce i barvu mohou mít stejnou. Ba co víc, do značné míry jsou ze stejných prvků (CHON). Liší se snad stůl od vola ve věcech, které zmiňuji?

Neberte to prosím osobně, je to jen oblíbené přirovnání.

[radix]

Tady by bylo spis lepsi srovnani stolu a zidle. V necem jsou podobne, v jinych ohledech jine. Ale pokud s nimi potrebuju ryt zahradu, tak jsou na tom oba podobne.

[Bystroushaak]

Imho na to líp sedí ta analogie o dukátu a praseti: Když musím letět jíst čepice, tak jsem omylem celé omegle.

[radix]

Mozna bych skoncil s tema prirovnanima (ktere jsou stejne vetsinou mimo) ... aspon v tomto pripade vubec nevim o cem je rec a ani google nepomaha :-/

[freshmouse]

Převzal jsem nedávno cizí kód přes 20k řádek v Pythonu a líbal bych autorům Pythonu nohy.

[Bystroushaak]

Python je krasne citelny na urovni par desitek radku v par metodach. Ne ve velkych projektech.

Related: Size Doesn’t Matter.

[radix]

Neco podobneho obcas slycham: "Ja pas v aute nepouzivam ... ridim opatrne a nejaky blbec v aute me muze zabit s pasem i bez pasu".

Na velikosti samozrejme zalezi.

[tacoberu]

Čitelnost Pythonu rohodně nezpochybňuji. Vadí mi, že když mám kód o mnoha a mnoha řádcích, tak musím všechny řádky pročíst abych zjistil jak kód použít. V tom je sice ta čitelnost super, ale v Haskellu nic takového nepotřebuji. I kdybychom předpokládali, že je hůře čitelný, tak se alespoň můžu spolehnout na signaturu. Takže mám funkci a hotovo. Neřeším, zda volá milion dalších řádků. V Pythonu je nejlepší to napsat znova.

[Mintaka]

E? Tyhle dva výroky, když jsou dohromady nějak nechápu:

[citace]Čitelnost Pythonu rohodně nezpochybňuji.// V Pythonu je nejlepší to napsat znova.[/citace]

Takže, čte se to dobře, ale raději to napíšu znovu??

Mnohokrát jsem byl vděčný za vlastnost Pythonu, že nemusím přepisovat kód v situacích, kdy několik mým starších (ale stále používaných) programů používá jednu knihovnu a v novém programu potřebuji rozšířit funkčnost funkcí/metod v knihovně. Díky defaultním hodnotám parametrů můžu zachovat funkčnost funkcí/tříd v knihovně, tak jak jsou staré programy zvyklé a zároveň tu stejnou knihovnu použít v novém programu, který si místo default hodnoty předá to co potřebuje. Samozřejmě je u toho potřeba myslet na zpětnou kompatibiltu a někdy od toho konceptu ustoupit.

Pozitivní vedlejší efekt je v tom, že se s tou knihovnou pracuje víc, udržuje se jedna verze a sem tam se vyladí i chyby, ze kterých profitují všechny programy, které tu knihovnu používají.

Právě to, že můžu určitou funkcionalitu izolovat do skořápky funkce/třídy/ modulu a příště ji už neřešit a jen používat, považuji za jeden ze základních kamenů programování a nejen velkých programů.

[tacoberu]

Takže, čte se to dobře, ale raději to napíšu znovu??

Musíš číst všechno. I to, že jsem na třísté řádce... Ano, pak zkousnu svou hrdost, a napíšu to znova pomocí knihoven které už znám. Což je přesně ten blbej efekt, který mi tak vadí.

K tomu zbytku, co píšeš: Ano, za tuto vlastnost Javy, PHP, Haskellu, C# jsem také vděčen. No a?

[Bystroushaak]

Chci vidět konkrétní případy.

[tacoberu]

Čeho prosimtě?

[Bystroushaak]

Těhle hrozivých pythonních problémů.

[tacoberu]

Rád bych ti vyhověl, ale nerozumím co po mě chceš.

[Bystroushaak]

Já tomu prostě nevěřím a považuji to za bullshit. Doslova veškeré mé zkušenosti mluví proti tomu, problém bych tedy hledal někde jinde.

[tacoberu]

Já tomu prostě nevěřím

OK.

Doslova veškeré mé zkušenosti mluví proti tomu

Popisuji jen mé zkušenosti, nic víc, nic méně. Beru si tedy z toho, že ty máš opačné. OK.

[Bystroushaak]

Popisuji jen mé zkušenosti, nic víc, nic méně. Beru si tedy z toho, že ty máš opačné. OK.

No a proto bych právě rád viděl ty ukázky.

[tacoberu]

Snažíš se vyvolat dojem, že ti nechci vyhovět? Nebo jak to mám chápat?

[Mintaka]

Já bych taky rád viděl ukázku programu, který je třeba celý přečíst a pak ho stejně bude nejlepší přepsat. Předpokládám, že do takového neblahého stavu se ten program nedostal kvůli vlastnostem jazyka.

[tacoberu]

A co s tím mám společného já?

[tacoberu]

Předpokládám, že do takového neblahého stavu se ten program nedostal kvůli vlastnostem jazyka.

Ačkoliv to vůbec nesouvisí s mojím příspěvkem, toto je docela zajímavá poznámka.

Když porovnám Haskell a Python, pokud v Pythonu začnu prasit, tak budu mět okamžitě problém s kolegy.

V Haskellu, když začnu prasit, tak pokud se mi kód podaří přeložit, tak mi kolegové začnou nadávat až v okamžiku, kdy můj kód budou muset refaktorovat. Dokavad ho mají jen používat, tak jsem v klidu.

Samozřejmě tato tolerance se týká jen střev. API funkcí a knihoven neokecám ani v jednom.

[Mintaka]

Re. ...pokud v Pythonu začnu prasit, tak budu mět okamžitě problém s kolegy:

Jestli ono to nebude v tom, že ten Python je dobře čitelný a pochopitelný, takže zprasený kód je tam snadněji vidět.

Až se kolegové naučí používat anlýzu kódu, třeba budou nadávat dřív i na tenn Haskel.

Analýza pro Python: http://pycallgraph.slowchop.com/en/master/

[tacoberu]

Tak možné je všechno.

On ten Haskell je čitelný stejně dobře jak Python. Jen není nutné, tak často koukat do zdrojáků. Což je pointa ke které směřuji.

[pavlix]

Haskell moc neznám, kam stačí koukat, že je to tak jiné než u Pythonu? Já osobně u Pythoních knihoven koukám nejčastěji do dokumentace. Do zdrojáků koukám, pokud chování dokumentaci neodpovídá nebo dokumentace chybí. Takto ovšem postupuju obecně, ne jen u Pythonu. Jediný zásadní rozdíl Pythonu je v tom, že leccos jde testovat na příkazové řádce.

[tacoberu]

Haskell jde testovat na příkazové řádce úpně stejně (ghc, online).

Pokud se na dokumentaci dá spolehnout, tak pak má výhrada padá.

[Bystroushaak]

Neco podobneho obcas slycham: "Ja pas v aute nepouzivam ... ridim opatrne a nejaky blbec v aute me muze zabit s pasem i bez pasu".

Ono je docela paradoxní, že zrovna smalltalk se používal a stále ještě používá pro spoustu industry grade software. Mimo jiné třeba v bankovnictví, ale viděl jsem použití i ve francouzské armádě. Jak si to vysvětluješ?

[radix]

Na "industry grade software" se pouzivaly a stale pouzivaji spousty jazyku, pocinaje assemblerem (nebo dokonce primo strojovym kodem). To samozrejme neznamena, ze je to dobry napad ...

Jinak Smalltalk znam jen z doslechu, pravdepodobne ma sve vyhody, ktere jej delaly (delaji) atraktivnim jazykem i pres jeho zjevne nevyhody.

[Bystroushaak]

Related: Size Doesn’t Matter.

Related: https://www.reddit.com/r/programming/comments/3xm490/why_java_tales_from_a_python_convert/ (ta diskuze, ne článek)

[tacoberu]

Na produkci?

Takhle prostě dynamické jazyky fungují a součástí práce programátora je postarat se, aby byl kód otestovaný dost na to, aby měl jistotu, že tam nikde nechtěné typy nepolezou a že aplikace umí případnou chybu zpracovat.

Opět zaměňuješ příčinu a následek. Dávej si na to prosím pozor.

[pavlix]

Já používám modul na coverage, který mi řekne, co mám pokryté a co ne.

To ti žádný program neřekne.

[Bystroushaak]

...

[Bystroushaak]

Lepší by bylo psát jen jedno (buď testy, nebo program, nebo typy), ideálně to, co je v daném případě nejjednodušší.

To by se mi líbilo, ale neumím si to představit v praxi.

[Radek Miček]

To by se mi líbilo, ale neumím si to představit v praxi.

Z typů vygenerovat program je úloha pro automatické dokazování (například v intuicionistické logice – viz třeba djinn).

Z testů vygenerovat program: na jedné konferenci letos byly hned dva příspěvky, které se tím zabývaly. V podstatě se zvolila "míra složitosti programu" a hledal se program v dané míře nejjednodušší, který projde testy.

[Bystroushaak]

Z typů vygenerovat program je úloha pro automatické dokazování (například v intuicionistické logice – viz třeba djinn).

To jsem viděl, ale imho to chce docela množství práce zas někde jinde.

[tacoberu]

Mě duck-typing nedává smysl v ničem. Jaká by měla být jeho výhoda? Zkus to prosím nějak shrnout. (Mě nenapadá žádná, ale jsem samozřejmě zaujatý.)

V tom že kód pak může být univerzální a využívat výhod existence zapouzdření? Speciálně u metod aplikujících nějaké operace na data dodaná v sekvenci to může dávat smysl.

Sorry, ale to vůbec není specifikum duck-typingu. Univerzální funkce umí Haskell parádně a navíc s jistotou, kterou mu dodají typy. V Javě to jde taky (například Iterable). V PHP taky (Traversable). Mě to smysl vůbec nedává. Naopak, přijde mi ten kód nebezpečnej, protože absolutně netuším, co to udělá, na čem to chcípne.

Chybu se dozvím nejenom až za běhu, ale až dost pozdě, až v okamžiku, kdy se runtime pokouší dobouchat na neexistující metodu, což je někde hluboko uvnitř střev, kde to vůbec neznám.

Ano. Proto je dobrým zvykem psát testy, které bys stejně musel psát tak jako tak.

No jistě, ale to neodpovídá na otázku, proč zvolit tento způsob, když nepřináší žádné výhody?

[Bystroushaak]

Sorry, ale to vůbec není specifikum duck-typingu. Univerzální funkce umí Haskell parádně a navíc s jistotou, kterou mu dodají typy. V Javě to jde taky (například Iterable). V PHP taky (Traversable). Mě to smysl vůbec nedává. Naopak, přijde mi ten kód nebezpečnej, protože absolutně netuším, co to udělá, na čem to chcípne.

Tím jsem nemyslel přijímat obecnou sekvenci, ale mít v sekvenci různé datové typy, nad kterými provádím konkrétní operaci. V případě interface by to předpokládalo, že všechny prvky v sekvenci mají společný interface, což nemusí být pravda. V případě vynucení interface to pak musíš řešit třeba konverzí. Ty jako programátor bys měl vědět, zda tam nějaká data patří, nebo ne a přijde mi neefektivní se o tom hádat se zabudovanými omezeními programovacího jazyka.

No jistě, ale to neodpovídá na otázku, proč zvolit tento způsob, když nepřináší žádné výhody?

To je tvůj subjektivní pocit, u kterého si opravdu nejsem jistý, jestli mám motivaci ho vyvracet. Například deklarované nevýhody se můžou zdát značné, ale v praxi jsou docela zanedbatelné. Prostě se s nimi setkávám jen velmi zřídka.

[tacoberu]

Sorry, ale to vůbec není specifikum duck-typingu. Univerzální funkce umí Haskell parádně a navíc s jistotou, kterou mu dodají typy. V Javě to jde taky (například Iterable). V PHP taky (Traversable). Mě to smysl vůbec nedává. Naopak, přijde mi ten kód nebezpečnej, protože absolutně netuším, co to udělá, na čem to chcípne.

Tím jsem nemyslel přijímat obecnou sekvenci, ale mít v sekvenci různé datové typy, nad kterými provádím konkrétní operaci. V případě interface by to předpokládalo, že všechny prvky v sekvenci mají společný interface, což nemusí být pravda. V případě vynucení interface to pak musíš řešit třeba konverzí. Ty jako programátor bys měl vědět, zda tam nějaká data patří, nebo ne a přijde mi neefektivní se o tom hádat se zabudovanými omezeními programovacího jazyka.

Já jako programátor kolikrát nemusím ani tušit, jaká data tam patří. Typy mi to řeknou (plus pro typy). Já jako programátor se můžu seknout. A má zkušenost mi říká, že čím dřív se to dozvím, tím lépe pro mě. (Další plus pro typy.) Některé typové systémy umožňují více datových typů jako omezení genericity sekvence. Je fakt, že to zase neumí každý jazyk. Můžu taky argumentovat, že obvykle v té funkci vím, jaké typy (alespoň generické) mají být obsahem té sekvence. Takže tak nějak furt nevidím problém.

No jistě, ale to neodpovídá na otázku, proč zvolit tento způsob, když nepřináší žádné výhody?

To je tvůj subjektivní pocit, u kterého si opravdu nejsem jistý, jestli mám motivaci ho vyvracet. Například deklarované nevýhody se můžou zdát značné, ale v praxi jsou docela zanedbatelné. Prostě se s nimi setkávám jen velmi zřídka.

Deklarované nevýhody mohou být marginální, ok. Ale chtěl jsem vědět ty výhody. A koho se nejlépe zeptat, než zapáleného pythonisty. Ale když ti to nestojí za to, tak asi nebudou tak jasné. Tudíž můj pocit nebude zase tak subjektivní :-P

[Bystroushaak]

Takže tak nějak furt nevidím problém.

Představ si, že máš tři různé API. Každé z nich vrací jiný druh objektu, všechny mají property třeba .time(), ale jeden implemetuje rozhraní Timed, další RecordedTime a třetí neimplementuje žádné. A pak máš čtvrté API, které provede analýzu časů, ale přijímá pouze třídy s rozhraním TimedRecord.

Tenhle bordel musíš celý nějak normalizovat a trávíš čas řešením kravin, místo algoritmem.

Ale chtěl jsem vědět ty výhody. A koho se nejlépe zeptat, než zapáleného pythonisty. Ale když ti to nestojí za to, tak asi nebudou tak jasné. Tudíž můj pocit nebude zase tak subjektivní :-P

Pls. Výhody jsem uvedl. Tobě se nezdají jako výhody. Samozřejmě, že bych ti mohl dokazovat, argumentovat a tak, ale imho je to prostě subjektivní záležitost. Svět není černobílý, věci mají své pro a proti a tobě se prostě některé proti zdají větší, než mě. Nechce se mi do toho ti to vyvracet. Byla by to zdlouhavá práce s nejistým výsledkem a nic z toho nemám, ani pocit, že to má smysl.

Jinak nejsem zapálený pythonista, snažím se vidět i nevýhody a temné kouty. Dělám v něm od roku 2007, z toho poslední roky více/méně každý den, tak prostě vím, co v něm jsou skutečné potíže a co jen jako potíže (unicode pain třeba) připadá často lidem, kteří přichází z jiných jazyků. Částečně taky proto, že jsem někdy kolem 2011 taky dělal v silně typovaných jazycích (Java, C#, D) a měl jsem pocit, že python je nějak nahovno. Jednoho dne mi ale došlo, že prostě nemůžu argumentovat s produktivitou, kterou v něm mám vyšší, tak jsem přestal řešit zdánlivé problémy, které ve skutečnosti nemám.

[tacoberu]

Takže tak nějak furt nevidím problém.

Představ si, že máš tři různé API. Každé z nich vrací jiný druh objektu, všechny mají property třeba .time(), ale jeden implemetuje rozhraní Timed, další RecordedTime a třetí neimplementuje žádné. A pak máš čtvrté API, které provede analýzu časů, ale přijímá pouze třídy s rozhraním TimedRecord.

Tenhle bordel musíš celý nějak normalizovat a trávíš čas řešením kravin, místo algoritmem.

Supr, tohle je hezký vysvětlení. A nebudu zde rozvádět, proč bych to dělal jinak, a proč si myslím, že by to bylo lepší

Ale chtěl jsem vědět ty výhody. A koho se nejlépe zeptat, než zapáleného pythonisty. Ale když ti to nestojí za to, tak asi nebudou tak jasné. Tudíž můj pocit nebude zase tak subjektivní :-P

Pls. Výhody jsem uvedl. Tobě se nezdají jako výhody. Samozřejmě, že bych ti mohl dokazovat, argumentovat a tak, ale imho je to prostě subjektivní záležitost. Svět není černobílý, věci mají své pro a proti a tobě se prostě některé proti zdají větší, než mě. Nechce se mi do toho ti to vyvracet. Byla by to zdlouhavá práce s nejistým výsledkem a nic z toho nemám, ani pocit, že to má smysl.

Trochu mi křivdíš. Chtěl jsem slyšet výhody. O nevýhodách jsem se zmínil jen pro motivaci, nijak jsem to dále nerozpitvával. Maximálně jsem uváděl na pravou míru výhody, které ve skutečnosti, objektivně, nejsou výhodami duck-typingu.

[Josef Kufner]

Typová anotace je ale velmi odlišná od statického typového systému.

Nevýhodou statického typování je, že typy musí být všude, což zbytečně mnoho věcí komplikuje. Nevýhodou dynamického typování zas horší přehlednost a těžší optimalizace.

Dynamické typování s anotacemi si bere to lepší z obou. Když to není potřeba, typy být uvedeny nemusí a metoda může být použitelná s čímkoliv, což se hodí u obecných knihoven. Ale pokud anotace uvedena je, IDE může napovídat a interpret jazyka optimalizovat.

[Radek Miček]

Nevýhodou statického typování je, že typy musí být všude, což zbytečně mnoho věcí komplikuje.

Aby se typy nemusely explicitně psát, lze použít typovou inferenci. Pokud typový systém nedovede něco otypovat (například API knihovny z dynamicky typovaného jazyka nebo API knihovny z jazyka s jiným typovým systémem), lze zavést speciální typ (např. dynamic v C#), na nějž lze převést libovolné hodnoty a naopak on sám lze použít na místě libovolné hodnoty.

Když to není potřeba, typy být uvedeny nemusí a metoda může být použitelná s čímkoliv, což se hodí u obecných knihoven.

Nedovedu si představit, proč byste metodu z obecné knihovny nechtěl otypovat. Většina metod nedokáže pracovat s libovolnou hodnotou – proč to tedy nepopsat v typu? A to platí dvojnásob, když ten typ ani nemusíte napsat explicitně.

[Bystroushaak]

Nedovedu si představit, proč byste metodu z obecné knihovny nechtěl otypovat. Většina metod nedokáže pracovat s libovolnou hodnotou – proč to tedy nepopsat v typu? A to platí dvojnásob, když ten typ ani nemusíte napsat explicitně.

Většina funkcí dokáže pracovat s druhem hodnoty. Například libovolnou sekvencí. Pokud to ale omezím jen na pole, či tuple, tak už budu mít problém, když tomu budu předávat iterátory, nebo generátory, nebo třeba můj rekurzivní objekt s definovaným .__getitem__(). Ono to vypadá, jako dobrý nápad, protože je to volitelné, jenže jak znám javisty, tak přijdou do pythonu a budou javit na plné koule, výsledkem čehož jsou knihovny na dvě věci (na nic a na hovno, kdyby někdo nevěděl).

[Radek Miček]

Většina funkcí dokáže pracovat s druhem hodnoty. Například libovolnou sekvencí.

Na to přeci stačí rozhraní.

[Bystroushaak]

Rozhraní v pythonu nejsou.

[Radek Miček]

Jen říkám, jak by to šlo staticky otypovat.

[Josef Kufner]

Teoreticky ano. Prakticky to hodně hází klacky pod nohy v okamžiku, kdy někdo s něčím nepočítal a není snadné to tam dopsat. Například když se propojují dvě knihovny, každá trochu jinak napsaná.

[Radek Miček]

Například když se propojují dvě knihovny, každá trochu jinak napsaná.

Jak ale v tomto případě pomůže, že tam ten typ (nebo rozhraní) nebude?

[Bystroushaak]

Pokud tam je, je funkce/metoda omezená jen na představivost autora, co všechno se do ní dá nacpat. Pokud tam není, dá se do ní nacpat cokoliv, co se do ní dá nacpat.

[Radek Miček]

Typ tohle přeci nemusí pokazit, typ může jen zablokovat to, co se tam napsat nedá.

[Bystroushaak]

Ano, může. Teoreticky, ve vesmíru, který je lidem nakloněn.

V praxi to tak prostě nebude, protože autor prostě nemá a ani nemůže mít představu, co tam cpát půjde a co ne. Je pravdou, že interface by tohle do určité míry řešil, ale taky to má chyby. Například co když jsou dva interface na syntaktické a funkcionální úrovni totožné, ale díky omezení jen na ten se kterým autor počítal tam ten druhý nejde nacpat? OOP prostě bylo od začátku (=smalltalk, ne java) vytvářeno s ducktypingem v mysli mixování s typovými systémy tohle paradigma rozbíjí a ubírá tomu hodně na kráse a eleganci.

[Radek Miček]

V praxi to tak prostě nebude, protože autor prostě nemá a ani nemůže mít představu, co tam cpát půjde a co ne.

Autor třeba ví, jaká metoda se vždy zavolá. Typ, který řekne, že hodnota na vstupu tuto metodu nesmí nemít (povoleny jsou tedy hodnoty, které ji mají a hodnoty, o kterých se to neví), přeci nic nepokazí, ne?

Například co když jsou dva interface na syntaktické a funkcionální úrovni totožné, ale díky omezení jen na ten se kterým autor počítal tam ten druhý nejde nacpat? OOP prostě bylo od začátku (=smalltalk, ne java)

Doporučuji jiný typový systém, než má Java. Třeba Scala nebo Typescript podporují strukturální podtypový polymorfismus. OCaml má řádkový polymorfimus.

OOP prostě bylo od začátku (=smalltalk, ne java) vytvářeno s ducktypingem v mysli mixování s typovými systémy tohle paradigma rozbíjí a ubírá tomu hodně na kráse a eleganci.

Jsou typové systémy, jenž duck typing podporují.

[Bystroushaak]

Autor třeba ví, jaká metoda se vždy zavolá. Typ, který řekne, že hodnota na vstupu tuto metodu nesmí nemít (povoleny jsou tedy hodnoty, které ji mají a hodnoty, o kterých se to neví), přeci nic nepokazí, ne?

No ale jak říkám, už třeba jen u sekvencí jde tohle velmi těžce. Protože sekvencí může být tuple, pole, slovník, iterátor, generátor, view, nebo třídy s definovaným iterátorem, nebo třídy s indexovacím a bool operátorem. Už jsem říkal, že python nemá interface, takže autor by tam musel vyjmenovat všechno tohle a stejně by pravděpodobně na něco zapomněl. Je to hned několik různých metod, které ale nemůže typovým systémem ověřovat (není možné kontrolovat existenci metod, to by musel dělat v kódu třídy). A co tím získáváme? Lepší nápovědu v IDE a (falešný*) pocit bezpečí?

*Je to dynamický jazyk, stejně to tam někdo může vrazit dynamicky a pak to spadne až za běhu.

[Radek Miček]

Je to hned několik různých metod, které ale nemůže typovým systémem ověřovat (není možné kontrolovat existenci metod, to by musel dělat v kódu třídy).

Proč to nemohu typovým systéměm ověřovat? Pokud to dokážu popsat v dokumentaci v přirozeném jazyce, je velmi pravděpodobné, že to dokážu i formálně v nějaké logice, což už je v podstatě typový systém.

No ale jak říkám, už třeba jen u sekvencí jde tohle velmi těžce. Protože sekvencí může být tuple, pole, slovník, iterátor, generátor, view, nebo třídy s definovaným iterátorem, nebo třídy s indexovacím a bool operátorem. Už jsem říkal, že python nemá interface, takže autor by tam musel vyjmenovat všechno tohle a stejně by pravděpodobně na něco zapomněl.

Typový systém může obsahovat typ Sequence, který pokryje všechny možnosti, jenž jste vyjmenoval.

Tuhle věc lze snadno zvládnout například ve Scale. Můžete si zavést typovou třídu Sequence a pomocí implicitních maker vygenerovat instance ke všemu, co připomíná sekvenci (například pro všechny třídy, jenž mají určité metody).

a (falešný*) pocit bezpečí?

To je podobné jako v ostatních staticky typovaných jazycích.

[Bystroushaak]

Proč to nemohu typovým systéměm ověřovat? Pokud to dokážu popsat v dokumentaci v přirozeném jazyce, je velmi pravděpodobné, že to dokážu i formálně v nějaké logice, což už je v podstatě typový systém.

Ah, takhle. Myslel jsem že se stále bavíme o tom type hintingu v pythonu. Tam to není možné.

[tacoberu]

No ale jak říkám, už třeba jen u sekvencí jde tohle velmi těžce. Protože sekvencí může být tuple, pole, slovník, iterátor, generátor, view, nebo třídy s definovaným iterátorem, nebo třídy s indexovacím a bool operátorem.

To je nějaká blbost ne? Sekvence je něčím definována. Tak třeba tím, že má metodu .__getitem__(). Takže prostě všechno to, co jsi vyjmenoval, tuple, slovník, iterátor, generátor a cokoliv nového, co si vymyslíš prostě musí definovat tuto funkci. To je všechno. Na tom není principielně žádný rozdíl. A nevím co brání tomu, aby se určil typ Sekvence, vynucující tuto funkci.

Abychom se vyhli problémů s pochopením, má otázka směřuje na to, v čem přesně ten typ u těch sekvencí škodí, či brání.

Ano, python nemá interface, to asi všichni víme. Ale co to přesně dokazuje?

[Bystroushaak]

To je nějaká blbost ne? Sekvence je něčím definována. Tak třeba tím, že má metodu .__getitem__(). Takže prostě všechno to, co jsi vyjmenoval, tuple, slovník, iterátor, generátor a cokoliv nového, co si vymyslíš prostě musí definovat tuto funkci. To je všechno. Na tom není principielně žádný rozdíl. A nevím co brání tomu, aby se určil typ Sekvence, vynucující tuto funkci.

Jednak ti imho nestačí jen __getitem__(), ale potřebuješ i velikost. Iterátor má jen AFAIK jen next() a __iter__(), ne? No a pak potřebuješ při definici typu OR, tedy buď metodu getitem & spol, a/nebo next() a __iter__(). Když to uděláš přes dědičnost, tak to nebude OR, ale AND, tedy všechny tyhle metody najednou.

Ano, python nemá interface, to asi všichni víme. Ale co to přesně dokazuje?

Pointa byla, že současný type hinting v pythonu ti AFAIK umožňuje kontrolovat jen, jestli jde o instanci nějakého konkrétního typu, ne jestli má ty a ony metody. A i kdyby ano, tak máš výčet metod delší, než samotnou deklaraci funkce.

[tacoberu]

Doporučuji jiný typový systém, než má Java. Třeba Scala nebo Typescript podporují strukturální podtypový polymorfismus. OCaml má řádkový polymorfimus.

Neměl by si prosím tě nějaké hezké porovnání mezi těmi jednotlivými druhy typových systémů? Dost v tom plavu, a zajímaly by mě rozdíly. Praxy chápu, spíše mi jde o ty nuance.

[tacoberu]

No, problem to bude. Ale tvrdil bych, že ten problem vytváří Python. Prinicipielně to problém není. I v to pitomém PHP existuje rozhraní Traversable díky kterýmu se té funkci dá předhodit pole, iterátor, generátor. A na array to bude skřípat jen proto, že je to nedotažený.

[Bystroushaak]

Jak už jsem psal; V pythonu interface nejsou, podporuje vícenásobnou dědičnost. To není „problém“, je to inherentní součást designu jazyka, která představuje „problém“ jen ve chvíli, kdy se z něj lidi snaží dělat javu, podle pořekadla „všechny imperativní jazyky jsou přece stejné“.

[Radek Miček]

porovname-li vyjadrovaci schopnosti jazyku

Ano, třeba v Pythonu můžete napsat

a = (1, [2, 3])
a[1] += [4]

a hádat, co to dělá.

[kyknos]

Hádat? :)

[Radek Miček]

Někteří lidé mohou být překvapeni, když zjistí, co to dělá.

[kyknos]

nepochybne, a?

[Radek Miček]

Typový systém by těmto problémům mohl předejít.

[kyknos]

jakym problemum?

jak jsem jiz psal, s pythonem jsem nadmiru spokojen, efektivnejsi jazyk neznam, nechci z nej delat dalsi javu nebo jinou mrdku :)

[Radek Miček]

jakym problemum?

Třeba, že ten kód mj. vyhazuje výjimku.

[kyknos]

smutne by bylo, kdyby ji nevyhazoval

[Radek Miček]

Ale on i změní hodnotu.

[kyknos]

porad nejak nechapu, co mas za problem

[Radek Miček]

Jednak, že chování Pythonu nedává smysl, a poté, že typový systém by mohl předejít případným nedorozuměním.

[kyknos]

ale prednosti pythonu neni, ze je to nejaka pancea proti nedorozumenim, holt se s nim musis naucit jako s cimkoliv jinym

prednosti je, ze se v nem prakticky a rychle pise, cemuz by ten tvuj typovy system nepomohl, spis naopak

[Radek Miček]

cemuz by ten tvuj typovy system nepomohl, spis naopak

Pomohl by tomu tím, že by některé nesmysly odhalil ještě před jejich vykonáním.

[kyknos]

za cenu zpomaleni prace a priblizeni pythonu k jinym, mene praktickym jazykum

na tom, ze nektere chyby odhalim az spustenim kodu, nevidim nic spatneho, ostatne takove chyby budou vzdy a vsude

[Strakac]

zbytecne se snazis, nekteri lide venuji vice energie ukazanim, ze jste idiot, misto venovani te energie tomu, nad tim co rikate premyslet.

ps. tim urcite nechci rict, ze jste idiot

[mirec]

a[1] += [4]

znamená

a[1] = a[1] + [4]

Najskôr sa vykonáva pravá časť výrazu, ktorá je v poriadku. Python nerobí deep copy (čo je logické keďže názvy premenných sú len značky), takže aj bez vykonania priradenia sa obsah zmení.

[Radek Miček]

a[1] += [4]

znamená

a[1] = a[1] + [4]

Nikoliv (v tom vašem kódu se obsah a nezmění). Správné vysvětlení je přímo ve FAQu. Je to ekvivalentní

result = a[1].__iadd__([4])
a[1] = result

[Radek Miček]

smutne by bylo, kdyby ji nevyhazoval

Proč myslíte? Měnit seznam přeci normálně jde. Koneckonců výše zmíněný kód stačí přepsat

a = (1, [2, 3])
b = a[1]
b += [4]

a výjimka se nevyhodí.

[kyknos]

přijde mi to logické :)

[Radek Miček]

Mně to moc logické nepřijde, očekával bych, že chování bude stejné jako u

a = (1, [2, 3])
a[1].__iadd__([4])

[kyknos]

holt kazdy uvazuje jinak, take neni nikde psano, ze musi kazdy pouzivat python, ze

[Bystroushaak]

V tomhle případě by bylo ideální použít append.

[Radek Miček]

Takze to, ze je referencni implementace pythonu 3 o par procent pomalejsi mi fakt zily netrha a jsem rad

Porovnáváte rychlost různých algoritmů v různých jazycích nebo stejného algoritmu v různých jazycích?

[kyknos]

porovnavam reseni jednoho problemu pri stejnem vynalozenem usili (case programatora) pomoci ruznych nastroju -> tedy ruzne jazyky a ruzne algoritmy

protoze pokud resim problem 1 hodinu v pythonu a 15 minut z toho stravim psanim kodu a 45 premyslenim o podstate problemu, zatimco kolega v C 45 minut pise kod a 15 minut premysli nad problemem, mam slusnou sanci, ze muj algoritmus bude o tolik lepsi, ze muj python dojde k reseni drive, nez jeho C

[Jendа]

Tip: osobně jsem nedávno začal psát v Pythonu i výkonově kritické aplikace, kde na algoritmech není moc co vymýšlet, např. oclvankus z deky. Pak jsem to spustil v profileru, přepsal jsem ty dvě funkce, kde to trávilo nejvíc času, do C, slepil Swigem, a výsledek je, že je to rychlé, a přitom nemusím ručně řešit spoustu pakáren se sítí, datovými strukturami a thready, co by mě potkaly, kdybych to psal v C celé.

[kyknos]

ano, to take

C, nekdy Julia

[Senior Database Programmer]

Strasna sekta tito pythonisti, uplne rovnako ako iphonisti sa napchaju do threadov o uplne niecom inom a spamuju/troluju tam.

[JZD]

Klídek dědo, klídek.

[freshmouse]

Ha, senilní patlač databází v PHP se rozčiluje!

[pavlix]

Podle mě se nejvíc o zprávičky o PHP zajímají ti, kteří PHP dříve používali, jsou rádi že se ho zbavili a fakt, že vycházejí nové a nové verze je trochu děsí.

[Bystroushaak]

Mě to neděsí, ale pobuřuje.

[pavlix]

Nebo tak.

[Michal Kubeček]

A proč by to vlastně někoho mělo děsit nebo pobuřovat? PHP má svou cílovou skupinu a své využití, pro které se velmi dobře hodí. Že ho mnozí používají i na něco jiného? Kdybychom měli zakázat všechny jazyky, u kterých se to děje, tak nám jich moc nezbyde. Pokud se pro vaše účely PHP nehodí, tak ho prostě nepoužívejte, proč vás pobuřuje, že si někdo dovolí ho dál vyvíjet?

[pavlix]

Kdybychom měli zakázat všechny jazyky,

Nikdo nic nezakazuje.

[Michal Kubeček]

Aspoň že tak…

[OldFrog {Ondra Nemecek}]

1++

[kozzi]

JJ, a to je ten problem. Jelikoz jsou to "ignoranti" a o modernim PHP nic nevedi :D. Ja jsem za kazde nove PHP rad. Jelikoz predstava ze nase aplikace musi bezet na PHP4 nebo treba i na PHP 5.2 me desi :D. Jinak pro vlastni projekty preferuji python, ale holt "musim" pracovat i v PHP.

Dneska neni problem v PHP psat prehledny a rychly kod.

[pavlix]

Kdyby další verze PHP nevycházely, tak bys v něm třeba pracovat „nemusel“, což je jedna z věcí, kterou takový „ignorant“ dokáže domyslet. :)

[kozzi]

Ano, to je pravda, ale bohuzel vychazej, takze opet koncim u toho ze jsem vlastne rad :). Samozrejme je skoda ze se na to nevykaslali uz driv a ja mel klid :). Ne ze bych stale nemel moznost zmenit praci a vyhnout se tomu, ale to by nebyla vyzva :D.