Forum >> Principianti >> Python è un linguaggio interpretato o è una Virtual Machine?

Pagina: 1

Ciao ragazzi,

da quello che ho letto, oltre ai linguaggi compilati ed interpretati ne esistono anche degli altri basati su una virtual machine ed approfondendo meglio la questine sembra proprio che Python sia uno di questi. adesso vi spiego quello che mi sembra di aver capito:

Python compila il codice sorgente in un formato intermedio chiamato "bytecode", il quale dovrebbe contenere tutte le istruzioni del nostro programma convertite in un linguaggio macchina specifico per un determinato microprocessore ideale su cui si basa la cosiddetta Python virtual machine. il senso di tutto questo si può riassumere in due punti:

1. velocità: il programma sarà probabilmente meno veloce rispetto ad un linguaggio compilato, ma sicuramente più veloce rispetto ad un linguaggio interpretato, perché il codice verrà avviato direttamente sulla virtual machine attraverso il "bytecode".

2. portabilità: questa caratteristica viene garantita dalla presenza della virtual machine contenuta in Python quando questo viene installato sul computer. il codice infatti verrà sempre compilato per la virtual machine e non per l'architettura su cui stiamo effettivamente lavorando.


adesso, a parte il fatto che non sono sicuro di quello che ho vi ho appena scritto, vorrei che gli esperti del sito mi aiutassero a capire meglio la situazione, per cui vi pongo alcune domande:

1. come mai quando si parla di Python le persone dicono sempre che è un linguaggio interpretato quando invece sembra essere una specie di ibrido?

2. la storia del compilatore di Python mi manda un po in crisi. quand'è che viene fatta la compilazione esattamente? quando salvo il mio file "script.py" attraverso il mio editor di testo? e quando sono nella shell interattiva? viene fatta anche in quel momento? comando per comando?

3. che senso ha compilare il mio script in un linguaggio macchina intermedio? non è meglio a questo punto compilarlo definitivamente per l'architettura finale su cui andrà eseguito, che sia per windows, linux, ecc.. ? certo in questo modo perdo la portabilità, ma almeno ci guadagno in prestazioni.




--- Ultima modifica di TurboC in data 2019-10-20 20:14:51 ---
Ma... scusa, ma la vera domanda sarebbe: che cosa ti importa di preciso saperlo? Questi sono dettagli implementativi che non hanno nessun impatto sulla tua possibilità di usare python...





Oltre tutto stai facendo un mischione molto confuso di concetti (come è anche normale che sia, se vuoi... visto che appunto si tratta di concetti piuttosto esotici che non influenzano minimamente il tuo uso di python tutti i giorni). Non esistono "linguaggi compilati" e "linguaggi interpretati", e sicuramante la "virtual machine" non è una terza opzione tra le due. Il "bytecode" non ha niente a che vedere con il "linguaggio macchina" (che poi, anche il "linguaggio macchina"... vabbe). Eccetera.





I concetti sono molto più sfumati e sovrapponibili... senza contare che le parole possono anche essere usate in modo libero, non-standard.


Ora, in primo luogo esistono "i linguaggi". Un linguaggio di per sé è un set di regole astratte. Poi ci sono le "implementazioni dei linguaggi". Un linguaggio può avere diverse implementazioni. Può esistere poi una "implementazione canonica" del linguaggio, quella a cui tutti implicitamente si riferiscono quando parlano di "linguaggio". Per Python, l'implementazione canonica è CPython, e se vogliamo parlare di come funziona CPython va benissimo, ma allora va detto che altre implementazioni funzionano in modo diverso riguardo anche ai concetti di "compilato o interpretato" etc.





Ora, sicuramente esiste un "interprete" CPython, per cui si può dire che CPython è un linguaggio "interpretato". Ma l'interprete di CPython "compila" anche il sorgente in bytecode, quindi si può dire che CPython è anche un linguaggio "compilato". Forse la cosa corretta sarebbe dire che CPython è "compilato in bytecode, quindi interpretato"... ma è più comune dire che i linguaggi di questo tipo (Java, per dire) sono "interpretati"... si fa prima e tanto poi ci sono talmente tante sfumature intermedie...


Intendiamoci: ci sono anche i linguaggi "solo interpretati", nel senso che non passano attraverso un bytecode di qualche tipo (almeno nella loro implementazione canonica): JavaScript, per dire.





Dall'altra parte della barricata, ci sarebbe da dire sulla differenza tra CPython e un "linguaggio compilato", ma qui le sfumature sono talmente tante... che bisognerebbe accertarsi di aver ben chiari i concetti, prima di affrontare il tema. Anche qui, basta dire che CPython non è un linguaggio compilato nel senso tradizionale del termine.





Poi c'è l'oscuro termine "virtual machine"... che viene usato un po' per bellezza, un po' a sproposito, un po' sì e un po' no. Boh. Posto che, in questo contesto, si sta parlando sicuramente di "VM a processo singolo" (perché altrimenti stiamo parlando di system virtualisation, e ovviamente non è questo che ci interessa qui), allora prima di tutto va detto che una VM di questo tipo è implementata con un interprete, guarda un po'. In sostanza è un interprete "pompato". Ora, si dice molto spesso (fin dalle origini di Python, e dagli stessi sviluppatori originari di Python peraltro) che Python gira su una "Python VM"... è corretto? Boh, sì, e perché no? Basta capirci che la "PVM" è una cosa diversa dalla Java VM, o dal CLR di .NET, che sono piattaforme designate per essere target di molteplici linguaggi. La "PVM" è in sostanza l'interprete Python. Alle origini di Python, il termine "PVM" era sostanzialmente un calco su "JVM" e voleva dire che Python poteva essere usato "alla Java" in tempi in cui questa comodità (write once, run everywhere) era tutt'altro che frequente. Ma va bene così, eh... non è solo una trovata di marketing: sicuramente la PVM fa molto lavoro in più per astrarre i dettagli dei sistemi operativi su cui lavora, rispetto per dire all'interprete di JavaScript (per l'eccellente ragione che JavaScript è pensato per girare in una speciale "virtual machine" chiamata browser).





Detto questo, per quanto riguarda le tue domande

> come mai quando si parla di Python le persone dicono sempre che è un
linguaggio interpretato quando invece sembra essere una specie di
ibrido?


Boh? Magari perché "una specie di ibrido" non vuol dire niente, mentre "linguaggio interpretato" è almeno una approssimazione della realtà? Ma poi, che ti importa di quello che dice la gente? Se vuoi sapere come funziona CPython, il sorgente dell'interprete è open source... puoi studiartelo... Altrimenti usa Python senza sapere se è "interpretato" o "una specie di ibrido" e va bene lo stesso...

> la storia del compilatore di Python mi manda un po in crisi...

Sì beh... di nuovo, ma che ti importa di preciso? Comunque (e sempre posto che stiamo parlando di CPython, perché "Python" in generale non ha senso), ovviamente quando salvi il tuo file non succede nulla (perché quello è il tuo editor, mica l'interprete Python... eh già). Quando *esegui* il tuo file, all'ingrosso l'interprete Python guarda se esiste già il bytecode (aggiornato) di quel modulo, altrimenti lo compila e poi lo esegue. La produzione del bytecode avviene a "import time", ovvero quando importi il modulo. La modalità interattiva non produce bytecode (tranne, ovviamente, dei moduli che eventualmente importi).


> che senso ha compilare il mio script in un linguaggio macchina intermedio?

Ma guarda, ti dirò di più: che senso ha che ci siano diversi tipi di computer e diversi tipi di sistemi operativi, e diversi tipi di linguaggi di programmazione in generale? Boh, onestamente non so. E' come va la storia, suppongo. E' una delle strategie classiche in cui vengono implementati i linguaggi di programmazione, da più o meno sempre. L'idea generale è di astrarre per quanto possibile il linguaggio dai dettagli del sistema operativo su cui si trova a operare, in modo che chi usa il linguaggio non debba anche preoccuparsi troppo della piattaforma sottostante. Ora, se questo comporta (ed è tutto da vedere... discorso complesso) una perdita di "prestazioni" (posto che tu arrivi a definire che cosa intendi per "prestazioni"... altro discorso complesso, fidati), allora... boh, è la vita: in parte vinci e in parte perdi. Se vuoi "le prestazioni", nessuno ti vieta di programmare direttamente nel linguaggio macchina specifico per la tua CPU. E infatti, talvolta si fa proprio questo. E poi guarda che comunque questo discorso vale anche per i linguaggi "compilati"... Anche C ha una "perdita di prestazioni".






Pagina: 1



Esegui il login per scrivere una risposta.