Brython (diskuse)

[Bystroushaak]

Ani nevím proč jsem to vlastně nepublikoval už dřív, teď jsem byl nějak líný to po sobě znova číst, tak doufám že to za ten měsíc a půl není moc outdated.

[Jendа]

Proč tak složitě? Nestačí si prostě spustit ve stránce počítač s Linuxem a Python provádět v něm?

[Bystroushaak]

Rychlost..

BTW; Zkoušel jsi do něj někdy dostat python? :) Já jo a moc sranda to není.

[xkucf03]

Hlavně bych uvítal, kdyby se konečně začaly psát pluginy pro nativní podporu „alternativních“ skriptovacích jazyků. Tohle překládání z jednoho do druhého je šíleně neefektivní, v podstatě se staví akorát další a další vrstvy abstrakce a systém se akorát zesložiťuje. Překlad do JS může zůstat jako náhradní řešení pro případ, že bude chybět nativní interpret.

[Jendа]

Vždyť v tom linuxovém počítači si můžeš spustit libovolnou aplikaci v libovolném jazyce.

(pozn.: vlákno jsem začal jako vtip, ale přijde mi, že se to tak fakt dělá)

[Bystroushaak]

Jenže to je plugin, tedy něco, co musíš uživatele donutit nainstalovat. Osobně jsem třeba k pluginům velmi skeptický a jen tak něco si do počítače nenainstaluji, už vůbec ne proto, že se v tom někomu chtělo programovat víc než v javascriptu.

Brython na druhou stranu funguje tak, že si toho uživatel ani nevšimne a jede slušně i na slabších strojích, jako je moje 5 let staré EEE.

[xxxxxxxxxxx]

dík, bude se hodit.

[mirec]

Ako myšlienka pekné ... ale ja neviem. Vývoj webov ma pomaly zabíja ... všetko je tu kompletne zlé. Jazyky sú zlé, ich použitie je zlé a ťažko sa niečo zmení prevodom python kódu na javascript. Nechápem ako niekto môže robiť weby. Nechápem ako je možné, že na obyčajnom google.com mi občas nefunguje história (majú tam riadenie back / forward pomocou js a občas to jednoducho nefunguje). Nechápem ako je možné, že nič nefunguje poriadne, nič nie je poriadne dotiahnuté, všetko funguje ako by tak na oko.

[Aleš Kapica]

Nechápem ako je možné, že nič nefunguje poriadne, nič nie je poriadne dotiahnuté, všetko funguje ako by tak na oko.

To víš. Jdou s dobou.

[xxxxxxxxxxx]

Nic není dokonalé a nikdy nebude. Všechno je to neustálý hon za dokonalým cílem, "fatamorgánou"...

[mirec]

Nejde o to, aby to bolo dokonalé, ale aby to aspoň nesmerovalo k horšiemu. Žiaľ ako tak sledujem vývoj webov tak to k horšiemu ide ...

[JS]

I kdyz priklon k webaplikacim chapu (je pro to mnoho praktickych duvodu), mate naprostou pravdu. HTML/CSS/Javascript jsou na psani slozitejsich aplikaci nevhodne. Data, ktera by v tlustem klientovi byla ulozena v pameti, se musi ve webove aplikaci serializovat/deserializovat a posilat po siti; a vymenou za tuto praci navic (ktera stoji pomerne drahou mobilni energii) dostanete bezpecnostni rizika a nutnost pripojeni k internetu.

Dale, desktopove aplikace scheduluje operacni system; na to, aby se browser stal rovnocennym operacnimu systemu zatim doba nedozrala. Vsechno, co uz v OS existuje leta, se na urovni browseru vynaleza znovu - bezpecnost, filesystem, izolace procesu..

[Kvakor]

Občas si říkám, že by minimálně u některých webů, co obsahují spousty Javascriptu, bylo opravdu výhodnější nechat běžet každý tab jako samostatn0 vlákno, protože potom by ho už plánoval systém a ne prohlížeč, kterému to jde jako kočce pastva. Nejhorší to je, když nějaký tab spotřebuje sto procent času jádra, na kterém prohlížeč běží, zatímco ostatní jádra jsou nevyužitá a přesto se nedá koukat na jiné taby.

[Bystroushaak]

Mě spíš zaráží, že to tak není. Mám úplně nový 6 jádrový počítač a stejně se firefox dokáže sekat na pitomé webovce, což je dost smutné.

[Jendа]

S webovkou, která dokáže vytížit i jen jedno jádro, je něco špatně.

[JS]

Podle me je to beznadejne. Javascript nema poradne knihovny, a hlavni sila Pythonu je prave v nich. I kdybychom si odmysleli vsechny problemy s prekladem, tohle zustane zasadnim problemem. Daleko uzitecnejsim a jednodussim projektem by bylo proste napsat (nebo slozit z uz existujicich) JS knihovny podobne Pythonu.

[Bystroushaak]

Vtip je tak nějak v tom, že můžeš vzít python zdroják a prostě ho importnout. Druhá věc je, že spousta z nich ti teď nepůjde importnout kvůli vnitřním bugům, další spousta pak bude k ničemu, protože práce s diskem, sockety atd.. se v prohlížeči nekoná.

[JS]

No prave, me prijde, ze dost podstatna a zajimava cast Python knihoven je napsana nativne v C, nebo na nich zavisi. Co treba pouzivam dost v posledni dobe je zabudovane sqlite. Takze je opravdu namiste otazka, kolik zdrojaku se takto da importovat.

[JS]

Navic, zase - nebylo to tu uz s Javou, pokus napsat skoro vsechno v Jave? Nakonec to bylo pomale, a proto je JVM tak velke. U noveho jazyka se tento pristup da pochopit. Ale nakonec se stejne bez nejake formy kompilace JS do nativniho kodu patrne neobejdeme.

[Bystroushaak]

No, já od toho neočekávám světovou dominanci, ani nic zázračného. Je to pro mě prostě jen zajímavý projekt.

Jinak velká výhoda pythonu je snadná manipulace s řetězci. Vždy když mám kus pythonu, ve kterém dělám různou řetězcovou magii přepisovat do něčeho jiného s vyjímkou D, tak bych brečel.

[JS]

No, k te manipulaci s retezci - nevim, jak je to treba v Perlu, ale s regularnimi vyrazy je nekdy docela opruz. Ale mozna opravdu patri k tem lepsim, co ja vim. Ale dokazal bych si predstavit, ze i Python na tom bude lepe - napriklad by mohl byt ve standardni knihovne nejaky parsovaci/lexerovaci modul, neco jako pyparsing.

Co konkretne se ti v Pythonu tak libi na praci s retezci?

[Bystroushaak]

Ale dokazal bych si predstavit, ze i Python na tom bude lepe - napriklad by mohl byt ve standardni knihovne nejaky parsovaci/lexerovaci modul, neco jako pyparsing.

Jo, pyparsing je fajn.

Co konkretne se ti v Pythonu tak libi na praci s retezci?

Slices, různé metody, jako .replace() atd.. Celkově prostě jednoduchost a intuitivnost, kdy píšu subjektivně polovinu toho, co třeba v javě.

[JS]

No me treba konkretne u regularnich vyrazu vadi, ze se porad musi testovat, jestli match == None. To je trochu nesikovne, ale mozna to pisu spatne.

Jinak standardni metody Pythonu (a slicy) na retezcich mi chybi v mnoha jazycich. Treba v .NETu.

[Bystroushaak]

No me treba konkretne u regularnich vyrazu vadi, ze se porad musi testovat, jestli match == None. To je trochu nesikovne, ale mozna to pisu spatne.

Mně u nich vadí, že je vždy do příště zapomenu, navíc je to nepřehledná slitá prasárna.

BNF u pyparsing mi přijde jako mnohem čistější řešení.

[pavlix]

Nějaké ty pythoní parsery jsem zkoušel, ale momentálně je mým naprostým favoritem Augeas.

[JS]

Tenhle Augeas? To jsem neznal.. Moc popisu tam neni, ale jestli to chapu spravne, ma to vlastni DSL jazyk na parsovani.. Docela pekne zda se, nevis, jestli existuje neco podobneho i na binarni soubory?

[pavlix]

Jo, tenhle. Na binární soubory netuším. Ale většinou se zpracovávají líp a pokud by byly komplikovanější, tak by možná stálo za to zkusit, zda by Augeas nakonec nešel i na ně, popřípadě ho upravit tak, aby šel.

[JS]

Ja myslim, ze mezi textovymi a binarnimi soubory jsou znacne rozdily, takze je tezko predstavitelne, ze muze DSL na popis jednech bude fungovat na ty druhe. Napr. v binarnich souborech je bezne, ze velikost nebo pozice zaznamu je ulozena ja binarni cislo (zatimco u textu se pouziva oddelovac). Nedovedu si predstavit, jak by tohle rozumne mohl cist textovy parser.

[pavlix]

Je fakt, že ty velikosti budou peklo. Ale stejně bych se jich zkusil zeptat, třeba budou vědět o nějakém jiném projektu.

[xkucf03]

Viz co jsem psal ve vedlejší diskusi – IMHO nemá cenu dělat na koleně nějaké vlastní parsování zvlášť u binárních formátů – binárních formátů či protokolů je už celkem dost a nemá valný smysl vymýšlet další – rozumné řešení je si vybrat nějaký existující* (meta)formát a k němu si dopsat vlastní slovník – řešit pouze tu sémantiku, názvy polí, struktury, datové typy… ale už ne, jak se to zakóduje (to už bylo vyřešeno a mnohokrát).

Nedovedu si predstavit, jak by tohle rozumne mohl cist textovy parser.

souhlas – binární a textové formáty jsou úplně jiné světy

*) tudíž k němu jsou i parsery a knihovny

[JS]

Ale ty jsi nepochopil, proc to chci - prave proto, ze jich je mnoho, by se hodil parsovaci DSL ktery popisuje bezne pripady. To neni o tom vymyslet vlastni format, ale byt schopen uniformne cist existujici formaty.

K cemu by takova vec mohla byt dobra? Napr. k inteligentnimi porovnavani, vyhledavani rozdilu, kompresi, atd.

[xkucf03]

DSL ktery popisuje bezne pripady

Jenže co jsou to běžné případy? Obávám se, že takový popisný jazyk by musel* být natolik bohatý, že by to byl běžný programovací jazyk… Spíš bych to řešil jako framework, do kterého by se daly psát moduly pro různé formáty – vstupem by byl proud bajtů a výstupem DOM, SAX nebo něco podobného. Framework by poskytoval funkce pro běžné úlohy (parsování různých číselných formátů, různé dekódování atd.), které by modul mohl volat a tím si ušetřit práci – ale kdyby na něco funkce nebyla, bylo by možné si ji v modulu napsat zcela bez omezení.

S tímhle si trochu hraju** v Javě: abys mohl načítat různé formáty, abstrahovat od nich a pracovat s těmi daty jednotným způsobem – data pak můžeš transformovat pomocí XSLT nebo nad nimi dělat XPath dotazy, i když to původně byly třeba INI soubory, JSON nebo třeba ASN.1.

*) jinak asi nepokryješ dost formátů, ale jen nějakou nezajímavou podskupinu (samozřejmě záleží, za jakým účelem to děláš – třeba máš vyhlídnuté formáty, pro které by to šlo – ale jako zcela obecné řešení mi to přijde utopie)

**) už je to nějakou dobu, teď to leží rozpracované v šuplíku

[Bystroushaak]

data pak můžeš transformovat pomocí XSLT

Wow, on někdo XSLT skutečně používá? Nedávno jsem se o to trochu zajímal a podle toho co jsem našel to působilo jako technologie, která nějak nenápadně umřela.

[xkucf03]

To má být vtip? Je tu sice XQuery, ale v některých ohledech je XSLT stále nepřekonané.

[Radek Miček]

v některých ohledech je XSLT stále nepřekonané

Třeba v ukrutné syntaxi

[xkucf03]

Je fakt, že nutnost psát if+else* pomocí tří elementů může některé slabší povahy odradit (ale má to svoje důvody a i něco do sebe…)

XSLT považuji za nepřekonané ze dvou důvodů:

• XSLT šablonu lze pojmout mj. tak, že odpovídá výslednému dokumentu (např. XHTML stránce, konfiguráku, ISDOC, SVG, LaTeX, TXT atd.) a sem tam obsahuje příkazy pro doplnění dynamických dat nebo nějaké větvení a cykly. Je to podobné jako původní myšlenka PHP – ale udělané lépe. Díky tomu se používá velice jednoduše – nízká vstupní bariéra, a XSLT šablony si tak může začít psát nebo upravovat i administrátor nebo obecně neprogramátor.
• Na elementy ze vstupu se aplikují šablony <xsl:template match="…">. Těch může být více a vybere se ta s nejlepší shodou (XPath dotazem). Šablona si udělá, co potřebuje, a pak může zase předat řízení dál pomocí <xsl:apply-templates/>. To, co by se v jiných jazycích muselo řešit pomocí spousty ifů, switchů a cyklů, máš tady bez práce.

*) nebo if, else if…, else – zatímco samotný if je jen na jeden element

[Bystroushaak]

Tak jsem na to teď koukal a začíná se mi to čím dál tím víc líbit. Máte někdo tip na dobrý tutoriál?

[xkucf03]

XSLT v příkladech od Jirky Koska. A taky se můžeš inspirovat u zdrojáků mého XML Web generátoru. Až se prokoušeš úplnými základy (celkem brzy) a začneš řešit konkrétní otázky, tak je stejně nejlepší STFW a většinu odpovědí najdeš na Stackowerflow nebo podobných webech.

Co se týče verzí XSLT: nejpřenositelnější je 1.0, ta funguje všude (např. xsltproc). Pak jsou obvykle podporovaná rozšíření EXSLT. Verze 2.0 je toho umí ještě víc, ale potřebuješ procesor, který ji podporuje – třeba Saxon (aptitude install libsaxonb-java, licence: Mozilla Public License version 1.0).

Taky koukni na knihovnu XSLT Standard Library.

Jako IDE se dá použít jEdit (spuštění transformace na jedno kliknutí) nebo cokoli na příkazové řádce (stačí zavolat xsltproc nebo saxon). V neposlední řadě můžeš použít běžný webový prohlížeč® jako např. Firefox a mít na začátku XML souboru:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="šablona.xsl"?>

a prohlížeč udělá transformaci sám a není potřeba ji dělat do souboru – stačí mačkat F5 v prohlížeči. (příklad BTW: takhle by podle mého měly vypadat konfigurační soubory – uživatel by k nim měl dostat schéma, aby vědět co tam psát, a taky šablonu, aby si mohl konfigurák zobrazit v prohlížeči v lidsky čitelné podobě a s výkladem)

[pavlix]

Touto fází jsem si taky prošel. A pak jsem začal přepisovat stromy rovnou z Pythonu. Výsledek byl méně standardizovaný, ale mnohem dříve hotový.

[Bystroushaak]

Nevím, to je jen můj dojem, který jsem získal po chvíli googlení před pár týdny.

[mirec]

Ja používam bežne (hlavne keď mi niekto mieri zbraňou na hlavu a chce po mne nejaký importný / exportný plugin pre libreoffice calc). No dobre, tú zbraň som si vymyslel

[Josef Kufner]

O knihovny nejde. Vem si napŕíklad, že máš na serveru kus kódu, který přepočítává nějaké datové struktury a pak je zobrazí do HTML. Udělá se HTTP GET, spustí se na serveru kus Pythonu, přepočítá se, pošle se klientovi vísledek. No a v okamžiku, kdy chceš udělat suprmoderní Javascriptovou aplikaci (třeba jen kvůli tomu, že server nestíhá), tak musíš tenhle kus Pyuthonu přepsat do Javascriptu, aby se klient nemusel ptát na každou blbost serveru, ale mohl si to spočítat sám. A to je přesně okamžik, kdy ti takovýto nástroj přijde vhod.

Další pěkným použitím je validace formulářů, kdy máš funkci, které dáš data z formuláře a ona řekne, co je špatně. To musí být bezpodmínečně na serveru, ale je velmi žádoucí to mít i na klientovi, aby to rovnou ukazovalo, co uživatel podělal. Nyní se taková pravidla píšou dvakrát, obvykle se použije knihovna se sadou běžných pravidel a speciality se řeší jen na serveru.

Další ukázkou je náhled komentáře před odesláním tady na AbcLinuxu. Kdyby bylo možné snadno vzít kód ze serveru a spustit ho na klientovi, tak bychom nemuseli mačkat čudlík "Zopakuj náhled komentáře"

[JS]

Uznavam, ze tohle je asi dobry use case. Otazka ale je, jak moc to takhle pujde, pokud s tim nebudu dopredu pocitat..

Ono o tohle se snazila uz Java.. Jenom o duvod vic proc jsou webove aplikace krok zpet.

[__dark__]

node.js :)

[Josef Kufner]

Jo, tohle jsem čekal

[diverman]

To, že prohlížeče neumějí nativně python, případně perl, ruby, apod. považuji největší handikep současného webu. Jen si představte programovat pro prohlížeč ve svém oblíbeném jazyce.

from jquery import jQuery

if __name__ == '__main__':
    jQuery('input[type="button"]').click(lambda but: but.css('display', 'none'))

[Bystroushaak]

Jo, to by bylo dost dobré, jenže pak by byla otázka, kde se vlastně zastavit. U pythonu? U ruby? U c? U bashe? Výsledný prohlížeč by pak mohl být krapet nekonečně veliký :)

[diverman]

Osobne by mi stacil ten python.

[Josef Kufner]

Jo, pak přijde někdo další, že chce Ruby, pak další, že PHP, pak další... bleeee.

[JS]

Kde se zastavit? To je jednoduche - predevsim oddelit jazyk a VM. Takova reseni uz tu byla - JVM, Flash (i kdyz ani jedno neni idealni). A nakonec obe padla z politickych duvodu.

[Acci]

Něco takového se chystá: asm.js.

[JS]

Jenze to neresi ten politicky duvod.. Pokud ten standard nepodpori MS, Apple a Google, nema to sanci.

[Acci]

Právě že řeší: program přeložený do asm.js dokáže zpracovat jakýkoliv JavaScriptový engine – jen Mozilla Firefox tyto aplikace bude zpracovávat rychleji.

[Acci]

A až se začnou objevovat benchmarky na webech, kde bude Firefox dvakrát rychlejší než Chrome, Google jej bude muset implementovat též.

[Grunt]

Petr Tomeš si změnil nick?

[pavlix]

Kde se zastavit? To je jednoduche - predevsim oddelit jazyk a VM.

+1

[Grunt]

Pamatujete operační systém EMACS? Tohle je dost podobné. Není nad to vypadnout s mobilem do přírody a při spuštění kalkulačky dostat hlášku o nepřipojení k síti a nebo naopak si nepřečíst kus textu v linksu, protože musí být ten text u klienta vygenerován (o pokročilých úkonech jako je třeba ebaniking z konzole nemluvím vůbec, to je víceméně vlhký sen).