Zamyslenie sa nad pythonom

2.8.2009 21:33 | comp | poslední úprava: 2.8.2009 21:35

Už som rok nepísal blog, tak to bude len podnet na krátke zamyslenie, nič viac.

Prečo nie je oficiálna implementácia Pythonu v Pythone, ale v C. Má Guido Radšej C ako Python? Alebo je Python na takúto úlohu úplne nevhodný jazyk?

Obecnejšie, veľa jazykov (presnejšie implementácií ich kompilátor/interpretrov) sa píše v C a nie v nich samých. Je to preto, že ľudia svojím vlastným jazykom neveria, nechce sa im kašľať s bootstrappingom, alebo čím to je?

       

Komentáře

[dizz]

myslim  ze je to zduvodu aby byl python rychlejsi. Prece jenom C je rychlejsi nez nejaky interpretovany jazyk.

[Marek Bernát]

Skutočne sa pri interpretovanom jazyku, ktorý je pomalý tak či tak, prejaví to, či interpreter je v C, alebo v pythone? IMHO bottleneck je inde ako v jazyku kompilátora/interpretru. A obecne pri kompilovaných jazykoch, alebo jazykoch, ktorých rýchlosť je porovnateľná s C tento argument vôbec neplatí. Navyše, tým, že sa kompilátor/interpreter píše v C, prichádza sa o všetky výhody Pythonu (prototype programming, duck typing, atď...) a je to skoro ako deklarácia, že C je na danú úlohu vhodnejšie, čo je od autora daného jazyka skutočne čudné

[Martin]

Pokud se nepletu, tak implementace Pythonu v Pythonu existuje (nebo se na ní alespoň pracuje). Takže buď se opravdu projevila jako pomalá nebo ještě není dokončena. Jiný objektivní důvod pro udržování oficiálního interpretu v Céčku než rychlost podle mě neexistuje. Ono snad dneska už neexistuje žádný důvod pro psaní v Céčku, než je rychlost.

[Let_Me_Be]

Pro psani v Cecku neexistuje opravdu zadny duvod, ani rychlost. Jedinou vyjimkou zustava totalni portabilita (prece jenom se stale daji najit pocitace kde je ANSI C kompilator, ale neni tam kompilator C++).

[Marek Bernát]

Čiže sa nikomu nechce srať s bootstrappingom  -- to som trafil. Len mi už nedošlo, že sa s nim treba srať nie raz, ale na každej novej architektúre, to mi už nedocvaklo. Díky!

[Let_Me_Be]

Trochu si to nepochopil Ja nemluvil o Pythonu, ale to je fuk.

[Marek Bernát]

Tak to prosím vysvetli. Vôbec netuším, čo som na jednej vete mohol nepochopiť

[Martin]

Napsal jsem, že jediným důvodem pro použití Céčka je v současnosti rychlost. Říkal jsem si, jestli se jistí lidé, v poslední době vystupující ve flamech C++ vs. C chytí. A oni se chytili a zcela podle očekávání namítli, že dokonce ani to Céčko dneska kvůli rychlosti nedává smysl, protože kód vygenerovaný C++ kompilátorem je rychlostně minimálně srovnatelný s Céčkovým kódem. A tak jediným důvodem pro použití Céčka je přenositelnost, protože ANSI C kompilátory jsou všude, ale C++ kompilátory bohužel ne. Příspěvek tedy nebyl o Pythonu. Resp. byl nejenom o Pythonu, ale o veškerém softwaru napsaném v Céčku.

[Marek Bernát]

Á, tak to som nevedel (zabudol), že pán je anti-Céčkar Ničmenej, aj keď to bol flame-bait, ja s tým 100% súhlasím. Pre použitie C (a C++ ) nevidím vôbec žiadny dôvod (sú vyššie jazyky s rovnakou rýchlosťou, napríklad LISP), preto mi ten skrytý význam unikol

[Martin]

Já si myslím úplně totéž. Aby náhodou nedošlo k omylu, když už si tu z lidí utahuju.

[Let_Me_Be]

Myslim ze ted si tomu dal finalni tecku a IMHO uz nikdo nemuze rict, ze by vedel jaky nazor vlastne zastupujes

(btw. ja se u techhle flamu skvele bavim, idealni relaxace po hodinach rypani se v ANSI C kodu)

[Martin]

Já píšu v C++ docela rád, momentálně je to můj hlavní jazyk. Ale zároveň se nemůžu postavit na něčí stranu, protože jsem schopen vidět i nedostatky. Teda vidím hlavně svoje nedostatky. Už jsem se totiž smířil s tím, že C++ zřejmě nikdy zcela nezkrotím a bude tedy lepší hledat štěstí někde jinde. Bylo by totiž smutné, kdyby moje práce využívala jen část potenciálu toho jazyka. Na to mám až příliš velkou hrdost.

[Marek Bernát]

Nádopotne. C++ je jazyk, v ktorom som napísal tisíce prográmkov a programov a je to tiež môj hlavný jazyk (alebo aspoň býval, už ho moc nepoužívam, ale stále neviem v ničom robiť tak ako v C++). Ale ovládnuť všetky jeho syntaktické a sémantické zákutia, to je robota na ďalších 10 rokov a tú už do toho skutočne nemienim investovať, zvlášť od doby, čo som zistil aké všetky má C++ nedostatky a objavil kopu iných geniálnych jazykov

[Martin]

Ano, moje chyba, měl bych to upřesnit:

"Ono snad dneska už neexistuje žádný důvod pro psaní v Céčku, než je rychlost. Pokud tedy náhodou nejste Šimon Tóth nebo Miloslav Ponkrác. " (vtip)

Snad jsem nikoho neurazil.

[Let_Me_Be]

Jee, mne by tak potesilo vytisknout ty zdrojaky skveleho C projektu na kterem ted delam (takova mensi programatorska archeologie) a omlatit ti je o hlavu.

Snad jsem ani ja nikoho neurazil

[Martin]

Já s C++ nemám žádný problém, to jen aby bylo jasno.

[Marek Bernát]

Mňa napadol ešte jeden dôvod: proste sa s tým tak začalo, či už preto, že na začiatku nebolo jasné, o čo sa vlastne Guido ide pokúšať a nemal ani žiadnu hrubú predstavu jazyka, v ktorom by rovno vedel napísať kompilátor, alebo proste nemal v pythone ešte veľkú prax (čo je bez kompilátora celkom pochopiteľné, dovtedy mal len papier ), no a keď už to v tom C bolo, tak sa mu to nechcelo prepisovať a tak to bobtnalo a bobtnalo a bobtná to dodnes

Na to PyPy sa pozriem, som zvedavý jak moc je pomalé. Ale tam skôr AFAIK ide o to, že ešte nie je zďaleka kompletné. Ale idem na to pozrieť, aby som nešíril FUDy

[Let_Me_Be]

To je ale pekna hovadina. To taky muzes tvrdit ze prekladem do asembleru se pripravis o vyhody C/C++/Cehokoliv.

Je docela zasadni otazka zda by bylo interpet pythonu jednodussi napsat v Cecku nebo v Pythonu. Ono to nemusi byt tak jednoznacne jak to na prvni pohled vypada. Ty vyhodu pythonu se musi na urovni interpretu nejak naprogramovat (z nizsich konstrukci).

[Marek Bernát]

To teda nie je hovadina. Ak je jazyk X lepší ako jazyk Y (či už objektívne, alebo pre niekoho subjektívne), tak jazyk X logicky používam na písanie všetkého kódu (alebo aspoň toho, ktorý sa v tom jazyku lepšie píše). Ak tak nerobím, tak musím mať nejaké zvláštne dôvody. Mňa zaujímalo, aké to sú.

Ad assembler: Kompilátor C (napríklad gcc) nie je napísaný v assembleri, takže to nie je validný argument Ničmenej, ak by bol, tak by si sa skutočne o výhody pripravil, je to presne rovnaké ako s tým Pythonom a C

To samozrejme zrejmé nie je. Ale ja som to ani nikde nepredpokladal. Tento blogpost sa práve pýtal, že prečo je upredňostňované C pred Pythonom. Ak je to ako hovoríš, tak beriem, ale nezdá sa mi to ako ten pravý dôvod.

[Let_Me_Be]

Hele, to realne rozhodnovani v podstate stoji na rozhodovani zda se pouzije nejaky fakt ultra simple boostrapovaci kompilator/interpret a vsechno ostatni bude implementovano v danem jazyku, nebo jestli se do toho kompilatoru/interpretu nacpe vic funkci (ta uroven se pak lisi podle jazyka). Cim mensi kompilator/interpret tim lepsi portabilita ale horsi rychlost.

[Marek Bernát]

Jasné, to beriem. Portabilita je IMHO jediný argument pre zvolenie jazyka hlavného kompilátoru (alebo aspoň toho minimalistického).

[mimi.vx]

a neni to proto ze na lovlevel system programovani je nejvhodnejsi C?

Prece jen kazdy jazyk je urcen na neco jineho ......

jinak guidovi je to celkem jedno viz: http://neopythonic.blogspot.com/2009/06/ironpython-in-action-and-decline-of.html

[Martin]

a neni to proto ze na lovlevel system programovani je nejvhodnejsi C?

Osobně tedy interpret Pythonu nepovažuju za nějaké echt systémové programování.

[Marek Bernát]

Low level -- možno. Hoci aj tam by som si dovolil polemizovať. Určite je najrozšírenejšie, ale nie nutne najvhodnejšie.

Ale na kompilátory, čo obecne nie je nič iné ako manipulácia textového súboru (kompilácia nie je nič iné ako zobrazenie "text jazyka" -> "text binárky"), určite nie je najvhodnejšie C, o tom by som sa mohol pokojne hádať

Nevidím tam žiadne jeho vyjadrenie k implementácii pythonu v pythone. A IMHO mu to určite nie je jedno, lebo by to de facto znamenalo, že jemu osobne sa v jeho vlastnom jazyku nepracuje lepšie ako v C, čomu sa mi skutočne nechce veriť.

[Martin Mareš]

To by mě zajímalo, jak se bootstrapuje interpreter

[Marek Bernát]

Aký je rozdiel medzi bootstrappingom interpretra a kompilátoru? Interpreter nie je nič iné ako on-the-fly kompilátor (veľmi zjednodušene povedané), nevidím tam veľký rozdiel. A o bootstrappingu kompilátora sa snáď rozpisovať nemusím, možnosti sú zrejmé. A ak ani to nie, odporučím Vás na wikipédiu

[Let_Me_Be]

Ten zasadni problem bude IMHO v tom ze ten novy interpret se bude muset interpretovat tim starym

[Marek Bernát]

Mrzí ma to, ale uniká mi pointa. Robíme si srandu z úplne bežného procesu bootstrappingu?

[Let_Me_Be]

Pokud mas kompilator tak ho muzes boostrapovat, protoze ti z toho vzdy vyleze binarka ktera se da dal normalne pouzivat. Interpret je porad interpret. A pokud chces mit boostrapovany interpret tak to znamena ze ten novy bude interpretovat tim starym (rekurznivne az k nejakemu pocatecnimu interpretu ktery neni v napsan v danem jazyku ale je zkompilovan).

[Marek Bernát]

Nerozumiem. Prečo by som mal písať interpret kvôli bootstrapovaniu interpretra? Napíšem si proste kompilátor

[alblaho]

Jenže napsat kopilátor jazyka, který obsahuje eval() je tak trochu přes ruku.

Jinak Python v Pythonu existuje, jmenuje se PyPy. Umí z podmnožiny Pythonu zvané RPython vygenerovat jiné kódy (C, Java Bytecode, JS, ...). Co se týče rychlosti, není to oproti CPythonu zas tak zlé. Jinak řečeno: je to zajímavý a docela slibný _výzkumný_ projekt.

[Marek Bernát]

Nebavím sa o náročnosti, je mi jasné, že s bootstrappingom je to veľmi nepohodlné, takže asi ľudia upredňostňujú jazyky, ktoré už fungujú všade (hoci dnes tam už patrí aj Python).

Jj, tiež som si to našiel. A k môjmu úžasu som zistil, že nie je určený len pre python, ale obecne pre ľubovoľný dynamický jazyk (ak sa niekomu bude chcieť napísať gramatiku, etc), takže je to v podstate taká mašinka, kam si človek zadá jazyk, architektúru, množinu optimalizácií a vypadne mu binárka. Veľmi šikovné

[cezz]

Ono je zaujimave projekt PyPy priebezne sledovat. Postupne robia rozne optimalizacie az do takej miery, ze dobiehaju CPython co do rychlosti. Navyse je to pomerne zaujimavy priestor na rozne pokusy, proste taka pythonova hracka.

[Martin Mareš]

No právě že Python je interpret, nikoliv kompilátor, takže nemůže být napsán sám v sobě.

[Marek Bernát]

He? Python je jazyk Ako taký sa dá napísať ako interpret aj kompilátor. Preto je možné bootstrappovať z kompilátora a to potom aplikovať na ten interpreter

[Marek Bernát]

A aby sme nepokračovali v blbej diskusii, priznávam sa, že som si pod pojmom interpret predstavil len jednu z dvoch možných realizácií (ale nápodobne aj Vy tú druhú), z toho vznikol rozpor.

[Ondrej 'SanTiago' Zajicek]

> Interpreter nie je nič iné ako on-the-fly kompilátor (veľmi zjednodušene povedané)

Kdepak. Interpret je obvykle implementovan tak, ze prechrousta program do nejake interni reprezentace, a tu potom sam interpretuje (proto take nelze udelat bootstraping - behem behu interpretovaneho kodu stale bezi interpret). Je mnohem jednodussi napsat interpret nez kompilator - interpret je v podstate bezny program, ktery se da napsat plne portabilne, zatimco kompilator je treba upravovat pro kazdou 'vystupni' architekturu. Nektere interprety mohou byt implementovane jako on-the-fly kompilatory do nativniho kodu, ale to jsou IMHO spis vyjimky (a bezny interpret pythonu AFAIK takovy neni).

[Marek Bernát]

Nerozumiem časti "interpret je v podstate bezny program, ktery se da napsat plne portabilne". Na konci celého interpretovania predsa aj tak musí byť vykonávanie inštrukcií, takže je zrejmé, že to bude závislé na danej architektúre

Je pravda, že v prípade obyčajného interpretru sa bootstrappovať nedá. Ja som práve bral tie on-the-fly kompilátory, som na ne zvyknutý z LISPu. Takže sa ospravedlňujem, že som spôsobil zmätok v diskusii

[petr_p]

Interpret je výpočetní stroj, který prochází vstupní kód (python), chápe jeho slova (syntaxe, sémantika) a jejich význam reflektuje ve stavu výpočetního/virtuální stroje, který je součástí definice vstupního jazyka (v pythonu to budou slovníky, objekty a tak). Tudíž pro běh interpretovaného kódu je třeba běžící interpret.

Tento přístup je velmi obecný, ale také velmi časové náročný. Příkladem je třeba bash nebo basic.

Proto se dnes emulovaný výpočetní stroj nahrazuje just-in-time překladačem, kde jednotlivé konstrukce „interpretovaného“ jazyka jsou přeloženy do funkcí emulujících výpočetní stroj a takto vzniklý strojový kód se nechá vykonat skutečným procesorem. Takže „interpret“ pak je ve skutečnosti překladačem do strojového kódu, který navíc poskytuje základní knihovnu funkcí jako je garbage collector a jiné jazykové specifické funkce. Klidně je pak možné vzít přeložený stroják, přilinkovat k němu onu základní knihovnu a vyplivnout standardní spustitelný soubor (třeba ELF) a ten pouštět zcela samostatně.

Takhle to dělá (nebo může dělat) JRE, perl nebo javascriptový interpret od Googlu.

[Marek Bernát]

To je všetko zrejmé, ničmenej to neodpovedalo na moju otázku, že ako môže byť interpreter nezávislý na architektúre? Samozrejme, že môže, ak beží nad virtuálnym strojom a teda vykonáva len virtuálne inštrukcie (v kontraste tým skutočným hardvérovým), ale toto AFAIK nie je prípad pythonu.

K tej just-in-time kompilácii: to je presne to, čo ja volám on-the-fly kompiláciou, možno len používam nesprávny termín. A presne tak to funguje pri mnohých LISPoch, človek si pracuje v REPL, ale je možné z toho dostať aj binárku.

[Ondrej 'SanTiago' Zajicek]

> To je všetko zrejmé, ničmenej to neodpovedalo na moju otázku, že ako môže byť interpreter nezávislý na architektúre?

Zdrojovy kod interpretu je nezavisly na architekture. Ten se pak prelozi normalnim kompilatorem.

> A presne tak to funguje pri mnohých LISPoch,

Ano, ale spousta (AFAIK vcetne Pythonu) takhle nefunguje, ale funguji vyrazne jednoduseji.

[Marek Bernát]

Môžeš to trochu upresniť? Je to presne to, čo som už písal, totiž, že interpreter pythonu bude v pythone a bootstrapping toho interpretru sa vykoná kompiláciou pomocou kompilátora pythonu v inom jazyku? Alebo myslíš niečo trochu iné?

Je to možné, ba priam pravdepodobné. Holt, neprichádzam s tými obyčajnými interpretrami veľmi do styku (aspoň nie priamo)

[Ondrej 'SanTiago' Zajicek]

Abys mel funkcni interpret pythonu napsany v jazyce X, potrebujes kompilator jazyka X. Napsat kompilator pythonu bude o dost tezsi, nez napsani (stavajiciho) interpretu, proto take nikdo nebude psat kompilator jenom kvuli bootstrapu. Obvykle se take bootstrap dela asi naopak - mas kompilator jazyka X napsany v jazyce X, a napises (nebo sezenes) bezny interpret jazyka X. V nem pak spustis ten kompilator na sebe sama.

[Marek Bernát]

To je samozrejme pravda, ale nejak sa mi zdá, že sám sebe odporuješ Pôvodne si písal "Zdrojovy kod interpretu je nezavisly na architekture. Ten se pak prelozi normalnim kompilatorem." Ja som na to odpísal, že interpret pythonu určite môže byť v pythone a je to nezávislé na architektúre a ten sa dá preložiť kompilátorom pythonu. Čiže presná realizácia tvojho príkladu. A ty si moju a teda (efektívne) aj svoju myšlienku odhodil, čo mi pripadá nekonzistentné. Takže som asi niečo nepochopil, keď sa mi zdá, že odporuješ sám sebe Čiže, jednotlivé tvoje príspevký sú úplne zrejmé, ale keď ich človek dá dokopy, tak nedávajú zmysel Please explain.

[Ondrej 'SanTiago' Zajicek]

Je to jednoduche. Tvuj puvodni dotaz byl, proc neni python napsany v pythonu.

Odpoved:

1) Guido van Rossum napsal interpret Pythonu.

2) Kdyby ho mel psat v Pythonu, tak potrebuje jeste kompilator Pythonu.

3) Kdyby existoval kompilator Pythonu, byl by interpret Pythonu vicemene k nicemu.

[Marek Bernát]

3 je sprostosť

[Ondrej 'SanTiago' Zajicek]

Tak tu 3) upresnim - nemelo by smysl psat novy interpret pythonu, protoze by interaktivni pythonove prostredi ('interpret') slo nejspis ziskat upravou kompilatoru.

Kazdopadne zadny kompilator pythonu neexistoval. A Guido van Rossum si sam zvolil latku 'napsat interpret', nikoliv o rad obtiznejsi 'napsat kompilator' (nebo interpret obsahujici JIT kompilator, to uz je jedno).

I kdyz je pravda, ze s vyuzitim kodu existujicich nastroju jako LLVM nebo backendu GCC by napsat kompilator nemuselo byt tak slozite.

[Marek Bernát]

S týmto upresnením súhlasím

[Citation Needed]

Neviem. Osobne si myslím, že hlavný dôvod je, že Guida to ani nenapadlo, proste to napísal v C (zrejme na počiatku nemal poriadne ani rozmyslené, čo ten jazyk má všetko robiť, čo je jasne vidieť na vývoji 1->2->3), proste to neriešil, už to tak zostalo. Plus tá portabilita a rýchlosť C tiež mohla hrať rolu.

[mimi.vx]

CPython je predelavan pomalicku s pouzitim LLVM viz http:/code.google.com/p/unladen-swallow/

rekl bych ze je to naopak .... kompilator je ta jednodussi volba ......

[:::]

> kompilator je ta jednodussi volba ......


se samotnym kompilatorem si nevystacis... vzhledem k tomu ze Python ma funkci eval kompilator bude stejne muset k vyslednymu kodu prilinkovat interpreter...

[Ondrej 'SanTiago' Zajicek]

> vzhledem k tomu ze Python ma funkci eval kompilator bude stejne muset k vyslednymu kodu prilinkovat interpreter...

Anebo na dany kod v runtime zavolat kompilator a vysledek prilinkovat a spustit.

[Marek Bernát]

Ak mi teda nechceš tvrdiť, že kompilátor je len lepší interpret (čo je možno pravda v prípade tých interpretrov, ktoré sú realizované pomocou on-the-fly kompilátorov, ale určite nie pri tých bežných) a inak je to úplne to isté

[Gilhad]

Kompilator: Vezme textovy vstup (zdrojak programu), chvili si neco pocita a vyplivne binarni vystup (prelozeny program). Ten vyplivnuty vystup je (trochu zjednodusene receno) ve strojovem kodu pro danou architekturu a proto jde spustit.

Pokud dostane kompilator spravny vstup (svuj zdrojak), tak jeho vystupem muze byt soubor, jez je kompilatorem a binarne s nim shodny. (cili prelozil sam sebe)

Interpret: Vezme textovy vstup, promysli si jednu radku a na zaklade toho neco udela (otevre soubor, napise hlasku, zmeni si stav nejake promenne ....). Vetsinou ten textovy vstup nepreklada do strojaku (ktery by pak spustil), ale rovnou interpretuje (stylem: Jestlize se ma udelat vystup na obrazovku, tak zavolam write(0, buffer, size) a on to uz system nejak udela)

Interpret sam je ve strojovem kodu, proto je spustitelny, ale jeho vystupem neni strojovy kod, nybrz data spoctena interpretovanym programem. Pokud dostane interpret jako svuj vstup svuj zdrojak, tak ho zacne provadet, cili po inicializaci to bude cekat na nejake zadani vstupu k interpretovani, ktere pak interpretovany interpret projde a pouzije funkce systemu (cili interpretujiciho interpretu) k vykonani te cinnosti. Cili napriklad interpretujici interpret pri provadeni interpretovaneho interpretu dojde k zaveru, ze interpretovany interpret chce psat na obrazovku. Takze si najde ve svych datech, co ten interpretovany interpret ma v dane promenne, jak se interpretuje vystup na obrazovku a pak zavola funkci systemu, na kterem bezi, aby to nejak zobrazil. Cili pro beh toho interpretovaneho interpretu je nezbytny interpretujici interpret, ktery ovsem musi byt spustitelnym kodem, cili vysledkem kompilace.

Abys mohl ziskat spustitelny interpret, tak musis zkompilovat jeho zdrojaky. Interpret sam o sobe nekompiluje, ten primo provadi. Cili pro interpret Pythonu napsany v C potrebujes prekladac C-> strojak. Pro interpret Pythonu napsany v Pythonu potrebujes prekladac Python->strojak. Ale interpret pythonu neni prekladac, ten pouze dela Python -> akce.

Takze bys nejdriv musel napsat prekladac pythonu do strojaku, nasledne bys musel napsat interpret pythonu v pythonu a ten tim predchozim prekladacem prelozit. Jenze napsat prekladac je slozitejsi, nez napsat interpret, zejmena pokud jazyk umoznuje programu interpretovat retezce za behu (cili se vlastne sam modifikovat na zaklade vstupnich dat)

[Marek Bernát]

To sú takmer všetko opäť raz zrejmé veci, navyše napísané tak zložito, že ak ich niekto neovládal už dopredu, tak ich z tohoto nepochopí ani omylom

Navyše, podobne ako Vaši kolegovia, používate implicitný predpoklad, že interpret != on-the-fly (just-in-time) kompilátor, čo nie je pravda, aj táto realizácia sa pomerne často používa

Samozrejme, že napísať kompilátor je zložitejšie. Ale ja som tu tú diskusiu o bootstrappingu interpretov nezačal (resp., jak sa to vezme. Založil som blogpost, takže si za to môžem sám ).

[Kvakor]

Ještě existuje jeden případ - překladač (translátor) v původním slova smyslu, co převádí jeden jazyk na druhý. Většinou je výstupem C (i když viděl jsem i C++ a Fortran) a musí se většínou linkovat vuči runtime knihovně (taky udělanou v c), co zajišťuje veškeré featury, které standardní knihovny neumí.

Nejznámnější jsou asi translátory pro Javu a Lisp, ale existuje spousta velmi exotických jazyků, které můžou být díky tomuto přístupu portabilní jako C. A navíc, napsat translátor je o dost jednodušší než napsat plnohodnotný překladač.

[razor]

Je to tak. Též to například dělá Eiffel.

[Marek Bernát]

Yup, to je ďalšia možnosť. Otázka je, či je výhodnejšie napísať prekladač python do binárky v C, alebo písať prekladač pythonu do C v pythone

[Deleted [8409]]

Není takto udělaný TinyPy? Kdysi jsem se díval na zdrojáky, ale už si to nepamatuju:)

[JS]

Odpoved na puvodni otazku proc: Kvuli rychlosti. Myslim, ze portabilita nebyla pro Guida podstatna v dobe, kdy to psal, a take, ze pro nej byla vzdy podstatna prakticnost, tedy chtel od zacatku Python jako jazyk z C rozsiritelny (z C protoze je to na Unixech nejpouzivanejsi jazyk, nebo byl v te dobe). Nechtel IMHO proste vytvorit novy Smalltalk - svet sam pro sebe, ale chtel neco, co budou lide pouzivat jako nadstavbu nad low-level kod v C. Musite si take uvedomit, ze to rozhodnuti padlo v roce 1991, takze tyto duvody teoreticky muzete oznacit za historicke.

Mimochodem, jde to vubec? Nejake zakladni funkce kazdeho jazyka musite napsat v C (nebo jinem kompilovanem jazyce), a to je IMHO prave to, co je napsane v C. Rada modulu zakladni knihovny byla poprve naimplementovana v Pythonu (nebo slo o vazby na existujici knihovny) a teprve pozdeji re-implementovana v C (napriklad pickle).

 

[Marek Bernát]

Ďakujem za odpoveď. Nechcel som nikoho napádať (a Guida už vôbec nie), len som bol zvedavý. A btw, argument rýchlosti nie je asi relevantný, pretože PyPy (implementácia Pythonu v Pythone, okrem iného) produkuje kód rýchlostne porovnateľný s CPythonom.

Dá sa to. Ten proces sa volá bootstrapping. Kompilátor jazyka X napíšete v jazyku X. Samozrejme vyvstáva otázka, ako ten kompilátor skompilovať. Možností je niekoľko: skompilovať to ručne do strojového kódu (znie to smiešne, kvôli obrovskej náročnosti, ale aj také príklady sú). Ďalšia možnosť je napísať minimálny kompilátor (v zmysle, že nepodporuje vlastnosti, ktoré treba na skompilovanie toho kompilátora a zároveň nerobí žiadne optimalizácie) jazyka X v jazyku Y. Tak sa skompiluje kompilátor v jazyku X a ten sa potom prípadne spustí sám na seba (ak chce človek získať zoptimalizovaný kompilátor). Ďalšia možnosť je cross-platformové kompilovanie, kde binárny kód pre danú architektúru vyrobíte z nejakej mašinky (takto funguje PyPy, vie vyrábať (nielen) Python konkrétne pre danú architektúru. Celkovo vzaté, nie je to jednoduchý proces, ale dá sa to.

Čo sa týka tej interakcie s C knižnicami, tak to má tiež svoje meno a volá sa to "foreign function interface". Nie je nutné písať kompilátor v jazyku C, aby mal podporu pre jazyk C. Ostatne a čo podpora ostatných jazykov než C? Tým sa toto vôbec neadresuje. Pomocou jednotného FFI môžete jazyk (do určitej miery) integrovať s hocijakým iným jazykom.

[alblaho]

Ďakujem za odpoveď. Nechcel som nikoho napádať (a Guida už vôbec nie), len som bol zvedavý. A btw, argument rýchlosti nie je asi relevantný, pretože PyPy (implementácia Pythonu v Pythone, okrem iného) produkuje kód rýchlostne porovnateľný s CPythonom.

PyPy je v podstatě jen jiný způsob, jak vyrobit ten C kód, který je u CPythonu psaný ručně. No a s tou rychlostí to žádná sláva zatím není, i když "řádově" už je to stejné. Dospěli k tomu po mnoha letech vývoje. Zkrátka: napsat interpreter v C je mnohem praktičnější a výsledný běh programu rychlejší.

[Marek Bernát]

Dík za upresnenie.

[JS]

Jiste ze muzete napsat kompilator primo v tom jazyce, a jiste ze muzete psat ten jazyk v necem jinem nez v tom, v cem ho chcete pak rozsirovat, ale proc se s tim delat? Guido nechtel psat kompilator, konec pribehu. Proto musel napsat jadro Pythonu v kompilovanem jazyce. Podle me to proste byla nejlogictejsi volba. A osobne si myslim, ze napsal v C prave tolik, kolik potreboval. Vsechna ostatni reseni, o kterych mluvite, jsou strasne pres ruku.

[Marek Bernát]

Nehovorím, že nie sú cez ruku. Ale prinášajú obrovskú výhodu: písať v svojom vlastnom jazyku a nie furt v C (čo je ostatne zrejme hlavný dôvod, prečo nové jazyky vznikajú: niekto si myslel, že sú v istých ohľadoch lepšie ako veľa ostatných jazykov). Pravda, pre interpreter sa to moc nehodí + portabilita C + rýchlosť C + už to v tejto diskusii bolo všetko rozobraté

[Filip Jirsák]

Schválně si porovnejte, co musí umět kompilátor, a co interpret Pythonu. Kompilátoru stačí umět načíst znak ze vstupu, vypsat znak na výstup a transformační tabulka. S tím interpret Pythonu asi nevyrobíte.

[Marek Bernát]

Veľmi Vám nerozumiem. Tá transformačná tabuľka je predsa bytekód (alebo iná interná reprezentácia jazyka) <-> strojový kód a rovnako dobre ju môžete použiť ako pri kompilátore, tak pri interpretri (pri interpretri proste vykonáte strojovú inštrukciu danú tabuľkou). Ostatne už to, že interpret sa dá realizovať ako JIT kompilátor vyvracia Vaše tvrdenie

[Filip Jirsák]

Jenže v trojici operací načti_znak, vypiš_znak a transformuj není žádná operace, kterou byste ten strojový kód mohl spustit. Což je právě ta podstatná operace/instrukce, která vám v interpretu chybí.

[Marek Bernát]

Mea culpa, máte pravdu.

[Sinuhet]

Ja nejak nevidim tu principialne vetsi narocnost operace transformuj oproti operaci spust. Proste misto aby add v tabulce ukazovala na string se dvema instrukcema, bude ukazovat na funkci ktere ta dve cisla secte.

[Filip Jirsák]

Jenže tohle musí být v bootstrapu. Takže jinými slovy musíte mít v bootstrapu implementaci všech operací, které (v tomto případě) Python má, a které nejdou vyjádřit pomocí jiných už definovaných operací. A to je právě ona nativní knihovna Pythonu (která navíc obsahuje ještě implementaci takových operací, které by bylo možné napsat v Pythonu s použitím ostatních operací, ale kvůli efektivitě je lepší mít je implementovány nativně).

[Sinuhet]

No pockat, resime situaci kompilator vs. interpret, bootstrapping je k tomuhle problem ortogonalni.

[Filip Jirsák]

Ne, řešíme dotaz Marka Bernáta v blogu „proč není interpret Pythonu napsaný v Pythonu“. A k tomu je jednoduchá odpověď: potřebujete nějaký kus nativního kódu, který spustíte hned na začátku, a pak potřebujete nativní implementaci všech základních operací.

[Sinuhet]

On tech dotazu polozil vic. Jestli jste si vybral tenhle, tak proc do toho tahate kompilator a srovnavate ho s interpretem?

Interpret pythonu napsany v pythonu nepotrebuje zadny kus nativniho kodu, jedine co potrebuje je funkcni kompilator/interpret pythonu (ale to je snad jasne).

[Filip Jirsák]

Jistě. Ale nějak musíte spustit ten první interpret/kompilator. Jinak vám tady klidně můžu představit báječný nový geniální jazyk, jehož interpret vyjde na jeden řádek kódu:

#!/usr/bin/env bajecny-novy-jazyk
runtime.interpreter.eval(io.file.read.byName(runtime.arguments[0]))

[Sinuhet]

To je ale preci jasne tak nak samo sebou, ze pokud mate program x napsany v jazyku y, tak pro ten jazyk y musite mit nejaky funkcni prekladac/interpret, jinak si svuj program muzete akorat vytisknout na triko. Uplne prvni prekladac cecka take nemohl byt napsan v cecku. Pokud ovsem mam funkcni prekladac/interpret pythonu/cecka (ktery jste trba napsal v assembleru), tak neni problem napsat prekladac/interpret pythonu/cecka v pythonu/cecku aniz bych potreboval nejaky bootstrapping nebo dodatecny nativni kod. (A porad nevim, jak do toho zapada srovnani kompiler vs. interpret.)

[Filip Jirsák]

Rozdíl je v tom, že k provozování programu v C (ze zdrojáku) na vašem počítači vám stačí dodaný kompilátor, pro provoz interpretovaného programu vám dodaný interpret v tom samém jazyce nepomůže.

[Sinuhet]

A na to jste prisel jak? Myslite, ze Guido nekde hluboko v utrobach zdrojaku pythonu ukryl podminku, ktera kdyz je detekovan pokus spustit interpret pythonu, tak ukonci program s chybou? A co kdyz v pythonu napisu interpret c++, taky me to vykopne? LISPu? Emulatoru x86 procesoru?

[Filip Jirsák]

Co na tom pořád řešíte? Vždyť je to úplně primitivní. Jak spustíte nějaký program v Pythonu (v tomto případě interpret Pythonu), když nemáte spuštěn žádný interpret Pythonu? Já jsem tady někde v diskusi uvedl interpret nového jazyka v tom novém jazyce. Už se vám ho podařilo spustit?

[Sinuhet]

Abych se priznal, ja ani nevim, co resim, protoze mi neni jasne, co vlastne resite a na co odpovidate vy.

A jak spustite nejaky program v cecku, kdyz nemate prekladac/interpret cecka? Uz jsem vam trikrat ruznymi slovy napsal, ze, pochopitelne, abyste spustil jakykoliv program v jazyku x potrebujete mit funkcni prekladac/interpret jazyka x. Prvni prekladac cecka nemohl byt napsan v cecku, prvni interpret pythonu nemohl byt napsan v pythonu. To ale neznamena, ze nelze napsat prekladac cecka v cecku a interpret pythonu v pythonu (a tim myslim ciste v pythonu, bez nejakych dodatecnych "nativnich" implementaci vybranych operaci).

[Filip Jirsák]

Program v céčku spustíte jednoduše tak, že jej nahrajete do paměti a ukazatel následující instrukce nastavíte na jeho začátek. V shellu jednoduše tak, že napíšete jeho jméno a zmáčknete Enter. Onen (přeložený) program v céčku je totiž v podobě, kterou dokáže interpretovat přímo procesor.

Pokud budete mít úplně čistý počítač jenom se shellem, někdo vám dá kompilátor C napsaný v C a zkompilovaný a k tomu zdroják nějakého programu v C, vy si ten zdroják můžete přeložit a spustit. Onen kompilátor vám totiž už přeložil někdo jiný.

Pokud budete mít úplně čistý počítač jenom se shellem, někdo vám dá interpret Pythonu napsaný v Pythonu a k tomu zdroják nějakého programu v Pythonu, můžete si tak akorát napsat vlastní interpret Pythonu v něčem, co dokážete přeložit do strojového kódu, a teprve pak si spustit ten program – a ten dodaný zdroják interpretu Pythonu můžete zahodit.

Rozdíl je v tom, že zatímco u kompilátoru do nativního kódu stačilo, že někdo jednou ten kompilátor přeložil, a ten se od té doby může šířit v binární podobě a může ho spustit každý. Pokud byste však chtěl šířit Python pouze jako interpret napsaný v Pythonu, musel by si každý sám znova napsat interpret v něčem jiném, co dokáže přeložit do spustitelného kódu. Pokud má mít každý možnost používat Python bez psaní vlastního interpretu, potřebuje nějaký nativní spustitelný program, který by mohl ten Python interpretovat. Ale nativní program už není programem napsaným v Pythonu.

Mimochodem, už se vám podařilo spustit ten interpret uvedený o pár komentářů výš?

[Sinuhet]

Tak predne bychom si meli vyjasnit terminologii. Programem v cecku jsem samozrejme myslel jeho zdrojaky, tzn. treba soubor "program.c" nikoliv vyslednou binarku.

Ve vasem priklade je mezi obema moznostma jeden zasadni rozdil. Zatimco ke zdrojakum prekladace cecka v cecku jste pribalil zkompilovanou binarku c prekladace, u pythonu jste z nejakeho duvodu funkcni (tzn. normalne spustitelny z toho shellu) interpret/prekladac nedodal. To je pak jasne, ze interpret napsany v pythonu (a jakykoliv jiny zdrojak napsany v pythonu) je mi k nicemu. Kdybych vam analogicky sebral tu binarku c prekladace, tak si taky neskrtnete.

Pokud oznacujete nativni prekladac cecka, vznikly ze zdrojaku cecka, jako "program napsany v cecku", proc by nativni prekladac/interpret pythonu, vznikly z pythonich zdrojaku, nemohl byt oznacen za "program napsany v pythonu"?

[Let_Me_Be]

Pokud by neexistovala binarni verze prekladace Cecka tak nemuzes psat prekladac/interpret Cecka v Cecku. Stejne jako nemuzes psat prekladac/interpet Pythonu v Pythonu. Co je na tom tak hrozne nepochopitelne.

[Sinuhet]

Ja nevim, co na tom kdo nechape, sam jsem to tu zopakoval asi ctyrikrat a stale se to neuchytilo.

[Filip Jirsák]

Jak tedy nazvete binárku vytvořenou ze zdrojáků v C? Spustitelný program v C? Dobře, pak ke spuštění spustitelného programu v C už nepotřebujete nic, ale ke spuštění spustitelného programu v Pythonu potřebujete stále interpret Pythonu.

u pythonu jste z nejakeho duvodu funkcni (tzn. normalne spustitelny z toho shellu) interpret/prekladac nedodal

Sláva, konečně se dostáváme k podstatě. Původní otázka byla, proč není interpret Pythonu napsaný v Pythonu. Odpověď je ta, že zdrojový kód programu v Pythonu a spustitelný kód programu v Pythonu je jedno a totéž. A něco, co je „normálně spustitelné ze shellu“ není programem v Pythonu (interpret Pythonu to nebude umět interpretovat).

[Sinuhet]

Nazvu ji proste program. Rikat binarce program v C mi projde podivne, to uz byste to rovnou mohl nazyvat "program v C, vimu, make a gcc".

Aha aha, takze jadro problemu bude v tom, za mate ponekud nekonzistentni nazvoslovi. Binarce vznikle zkompilovanim c zdrojaku rikate "program v c", ale u pythonu jsou "programem v pythonu" pouze zdrojaky. By me zajimalo, jak rikate programum napsanym v c/c++, ktere jsou spousteny c/c++ interpretrem, takze zadny binarni soubor nevznika. A take jak byste nazval nativni program, vznikly kompilaci pythonich zdrojaku (pokud by pythoni kompilator do nativniho kodu existoval, coz jiste teoreticky mozne je).

Takze kdyz svou myslenku preformuluji: mam binarni, nativni, "nezdrojakovy", na procesoru primo bezici program, ktery umi interpretovat textove zdrojaky pythonu. Potom je mozne zkonstruovat takovy pythoni textovy zdrojak, ze jeho spustenim v existujicim binarnim interpretru vznikne bezici program, ktery je schopny nacist textovy nebinarni zdrojak v pythonu a vypsat binarni nativni soubor, ktery po spusteni v shellu bude presne vykonavat prikazy, popsane v nactenem zdrojaku pythonu.

Souhlasite?

Pokud ano, tak jiste lze ucinit ruzne modifikace, napr. ze vystupem nebude binarni nativni soubor, ale dojde primo k interpretaci nactenych pythonich zdrojaku a provedeni prikazu (takze to bude interpreter v interpretru). Voila - interpreter pythonu napsany v pythonu!

[Filip Jirsák]

Názvosloví je sice nekonzistentní, ale ono se takhle běžně používá. Označení „program v Pythonu“ znamená, že k jeho spuštění budete potřebovat interpret Pythonu. Kdyby se Guido rozhodl napsat jazyk kompilovaný do nativního kódu, mohl jistě napsat kompilátor Pythonu v Pythonu, nějaký první kompilátor pre-Pythonu napsat v čemkoli, pak zkompilovat první kompilátor Pythonu napsaný skutečně v Pythonu, a onen kompilátor pre-Pythonu klidně zahodit. S interpretovaným Pythonem tohle nejde, s ním potřebujete na každém počítači, kde má Python běžet, nějaký zavaděč, který není v Pythonu (běží jinak, než v interpretru).

Voila - interpreter pythonu napsany v pythonu! Váš komentář

Kdepak. Pořád tam máte onen nativní zavaděč, takže onen interpretr není celý v Pythonu. A o v původním příspěvku evidentně šlo – pokud by šlo jen o to, proč není nějaká část interpretru, byla by jediná správná odpověď „ale ona je“. Stačí si třeba vzpomenout na funkci eval.

[Sinuhet]

Vasi nomeklature fakt nehovim. Django take neni cele v pythonu, protoze na jeho spusteni potrebujete "zavadec", aka interpreter? To vlastne znamena, ze neexistuje zadny program zcela napsany v pythonu, protoze zatim mame jenom interpreter. Az nekdo napise kompilator, tak mavnutim kouzelneho proutku najednou vsechny programy, ktere nebyly zcela v pythonu, zcela v pythonu budou?

Abychom to shrnuli: jde vyrobit takove zdrojaky v pythonu (a tim nemyslim jednoradkovy eval), ze po jejich spusteni (at uz iterpretrem nebo po kompilaci) bude tento program schopen spoustet/kompilovat jine pythoni zdrojaky. Vy jste se zasekl na tom, ze kdyz tento interpretr/kompilator budu chtit spoustet v pythonim interpretru, budu muset mit ten interpretr po ruce. To je samozrejme pravda, ale ja v tom nevidim principialni prekazku, ktera by jaksi branila python v pythonu napsat.

Skutecny duvod, proc neni prakticke (nikoliv nemozne!) vytvaret interpretr pythonu napsany v pythonu kdyz ho muzeme spoustet jenom v dalsim interpretru pythonu, je ten, ze upravama pythonich zdrojaku naseho interpretru neni mozne provadet bugfixy/optimalizace/rozsireni v nativnim interpretru, takze bychom vzdy byli limitovani tou nativni verzi.

[Filip Jirsák]

To je samozrejme pravda, ale ja v tom nevidim principialni prekazku, ktera by jaksi branila python v pythonu napsat.

Principiální překážka to samozřejmě není. Akorát když budete mít jedinou implementaci kompilátoru/interpretu Pythonu, a tou bude právě interpret v Pythonu, můžete na něj akorát smutně koukat. No a pokud nechcete hned na začátku psát těch interpretrů víc, je dobré napsat právě ten, který půjde spustit nativně.

[Marek Bernát]

Vyjadrujte sa jasnejšie. Python != interpreter Pythonu. Zdrojový kód v pythone a spustiteľný kód v pythone má rovnaký dichotómiu ako v každom inom jazyku. Zdrojový kód je ten jazyk samotný a spustiteľný kód je bytekód nejakej mašiny (či už virtuálnej, alebo reálnej). Nie, pôvodná otázka bola, prečo nie je kompilátor/intepreter pre python napísaný v pythone, nešlo o to, že priamo interpreter, to je tam nepodstatné. A ako sinuhet správne podotkol, tých otázok tam bolo oveľa viac. Zrovna ste si vybrali tú, ktorá je úplne zrejmá a nikoho nezaujíma a navyše ste to tak domotali, že tu vznikla ďalšia 10 komentárová diskusia o ničom, ktorá spočíva len na vzájomnom nepochopení

[:::]

hele, mohl bys v tyhle diskuzi (i v dalsich) mluvit bud cesky nebo anglicky? Protoze jak to tady procitam tak tvym argumentum ani trochu nerozumim a nejsem si jistej jestli je to tim ze jsou nesmyslny, nebo tim ze je mezi nama jazykova bariera. Diky.

[Marek Bernát]

So whatcha don' get, nigga?