Domanda L'interprete Python

[TheSeeker]

Ho aperto questo topic per capire meglio ciò che ho letto sull' interprete Python, quindi se dico qualche boiata, ci prego di correggermi [MENTION=100068]cat[/MENTION]yya e [MENTION=212484]Berserkr[/MENTION]

Allora Python è un linguaggio interpretato, nel senso che abbiamo inizialmente il codice sorgente, ovvero il classico file .py, questo file viene poi tradotto (ma in certe circostanze) in un formato bytecode che viene eseguito più velocemente che del classico codice sorgente.
Chi si occupa di eseguire è ovviamente la Python Virtual Machine, non si tratta di un software indipendente ma può essere visto come un loop gigante che non fa altro che eseguire una ad una le istruzioni nel nostro codice sorgente o relativo bytecode.

Il bytecode é una rappresentazione del nostro codice sorgente indipendente dalla piattaforma e che viene eseguito più velocemente dalla PVM che del classico codice sorgente, ovviamente il bytecode viene rigenerato ogniqualvolta modifichiamo il nostro codice sorgente, i file .pyc (ovvero contenenti il bytecode) a partire da Python 3.x sono raccolti in una cartella chiamata __pycache__ nella directory di lavoro.


Un compilatore, ovvero che traduca il nostro sorgente in un file eseguibile, non esiste ancora ma niente vieta che venga creato più in là.

 

[Utente cancellato 210785]

Quasi tutto giusto.

Da quanto so, PyPy ha integrato un JIT (Just In Time) Compiler

PyPy - Welcome to PyPy

(peccato, non c'e' la versione a 64 bit per Windows!!! )

Ma queste sono informazioni che trovi tranquillamente si Wikipedia.

Devi pensare alla domandona

 

[TheSeeker]

Da quanto so, PyPy ha integrato un JIT (Just In Time) Compiler

Si ne ho sentito parlare

Devi pensare alla domandona

Un aiutino

 

[luzzi]

Se vogliamo mettere i puntini sulle i giusto per essere precisi.

La "differenza" di esecuzione tra py e pyc è legata esclusivamente al py che deve essere convertito in byte-code in memoria.
Non esiste un vero e proprio applicativo che permette il passaggio ad exe se non py to exe che è leggermente diverso.
Se ti stai interessando all'ambiente di lavoro python ti suggerisco di andare a documentarti sull'allocazione in memoria e la gestione delle risorse.

 

[Berserkr]

Sinceramente, se ti stai sbattendo perché sono saltate fuori discussioni sulle prestazioni, ti sconsiglio di sbatterti, mentre se lo stai facendo per puro scopo informativo, continua.

Sconsiglio perché le discussioni sulle prestazioni sono rilevanti fino ad un certo punto. La gente sviluppa in qualsiasi linguaggio di programmazione, anche in linguaggi molto più lenti del python e non si fanno problemi, perché loro non devono fare benchmark; lavorare a basso livello; sviluppare il nuovo cry engine 4; sviluppare il nuovo after effects, eccetera. Prendi esempio da quello di openshot: ha fatto un ottimo editor con un linguaggio che alcuni lo considerano troppo lento per loro, eppure l'editor va molto meglio di un editor come kdenlive che è scritto in c++ e che, dopo 3 effetti, crasha e lagga come non so cosa.

Il python non sarà super prestante, ma di certo è un bel linguaggio con cui sviluppare e divertirti mentre sviluppi, senza dover bestemmiare per un crash dove nemmeno il debugger sa dove andare a parare. La tecnologia va avanti e con essa anche i linguaggi di programmazione diventano sempre più moderni e il GC e le VM si faranno sempre più presenti nei linguaggi futuri.

P.S: Ok, non sono in tema, però ho fatto questo stupido discorso perché, secondo me, questa cosa di informarti è nata da alcune discussioni dove si era parlato anche delle prestazioni... sicuramente mi sbaglio e sicuramente avrò detto qualche cazzata, però spero di aver fatto capire il concetto XD.

 

[TheSeeker]

Sinceramente, se ti stai sbattendo perché sono saltate fuori discussioni sulle prestazioni, ti sconsiglio di sbatterti, mentre se lo stai facendo per puro scopo informativo, continua.

Sconsiglio perché le discussioni sulle prestazioni sono rilevanti fino ad un certo punto. La gente sviluppa in qualsiasi linguaggio di programmazione, anche in linguaggi molto più lenti del python e non si fanno problemi, perché loro non devono fare benchmark; lavorare a basso livello; sviluppare il nuovo cry engine 4; sviluppare il nuovo after effects, eccetera. Prendi esempio da quello di openshot: ha fatto un ottimo editor con un linguaggio che alcuni lo considerano troppo lento per loro, eppure l'editor va molto meglio di un editor come kdenlive che è scritto in c++ e che, dopo 3 effetti, crasha e lagga come non so cosa.

Il python non sarà super prestante, ma di certo è un bel linguaggio con cui sviluppare e divertirti mentre sviluppi, senza dover bestemmiare per un crash dove nemmeno il debugger sa dove andare a parare. La tecnologia va avanti e con essa anche i linguaggi di programmazione diventano sempre più moderni e il GC e le VM si faranno sempre più presenti nei linguaggi futuri.

P.S: Ok, non sono in tema, però ho fatto questo stupido discorso perché, secondo me, questa cosa di informarti è nata da alcune discussioni dove si era parlato anche delle prestazioni... sicuramente mi sbaglio e sicuramente avrò detto qualche cazzata, però spero di aver fatto capire il concetto XD.

No, é a scopo informativo, sto leggendo Learning Python per approfondire il linguaggio cosi volevo vedere se ciò che avevo imparato era giusto.

 

[Utente cancellato 210785]

@Bersekr: non si sconsiglia mai nulla.

La curiosita' va sempre soddisfatta. Magari poi, delle informazioni che hai ottenuto, non te ne fai nulla, ma rimane comunque un'altra tessera del mosaico delle conoscenze che uno possiede. Del tipo: questa la so!

Vero, le prestazioni pure non hanno molto senso: per un'interfaccia utente, un programma che risponde in un microsecondo o in un millisecondo, dal punto di vista dell'utente non cambia assolutamente nulla: tanto sono i tempi umani che controllano l'utilizzabilita' del programma.

Se devi fare tanti calcoli, invece, un microsecondo e' decisamente meglio di un millisecondo: vuol dire che in un millisecondo puoi fare un numero di calcoli tre ordini di grandezza superiore!

Come dicevo, Python va benissimo come collante, per semplici script.

Al momento lo sto utilizzando per un generatore di boschetti

Tecnicamente e' un generatore di scene 3D in cui la scena deve avere tutta una serie di proprieta' fisiche specifiche, ma visto che uso gli alberi come pianta di riferimento, ecco il termine

Il programmino non e' proprio banalissimo: solo per il generatore sono 2200 righ di codice. Poi ci sono le varie librerie per navigare nei database (che non sono fatti con MySQL) delle piante, dei terreni, dei satelliti, ecc.

I problemi fondamentali sono:

1) la mancanza del controllo sui tipi
2) la mancanza di controlli sui simboli usati ma non definiti. Magari per errore scrivi scnee invece di scene e te ne accogi solo all'esecuzione.

 

[Berserkr]

Beh, certi errori i programmatori li devono evitare, non solo il python scopri errori solo all'esecuzione. Sta anche al programmatore fare un minimo di attenzione mentre programma.

 

[Utente cancellato 210785]

Beh, certi errori i programmatori li devono evitare, non solo il python scopri errori solo all'esecuzione. Sta anche al programmatore fare un minimo di attenzione mentre programma.

Questa e' la teoria

La pratica insegna che l'errore e' all'ordine del giorno, la memoria e' labile, il pensiero logico fallace, la concentrazione saltuaria.

Ed e' per questo che piu' lavoro fa la macchina, meglio e'!