Closed cstrap closed 7 years ago
Credo che il -m equivalga al -r di irb, per caricare un modulo senza dover scrivere il require.
$ cat a.rb
puts "ciao"
$ irb -r ./a.rb
ciao
2.4.0 :001 >
Non avevo mai visto i .pyo. L'esistenza o meno di un bytecode Ruby dipende dall'implementazione, ma credo sia lo stesso con Python.
Per esempio il bytecode di JRuby è quello della JVM. Quello di altri interpreti come Rubinius o Truffle sono codici loro. MRI, l'interprete standard, ha una Instruction Sequence in cui si può compilare il codice, salvarla e poi ricaricarla da file. Ho provato e sulla stessa macchina funziona, tra macchine diverse non sempre. A quanto ho capito è pensato per uso interno all'interprete e non per la distribuzione.
Tanto tempo fa qualcuno aveva scritto https://github.com/whymirror/unholy per compilare Ruby in pyc :-)
python
oltre a lanciare la REPL, ha una serie di opzioni interessanti, solo per citarne alcune:-O
ottimizza il bytecode generato, eliminando ad esempio leassert
, con un estensione.pyo
-m
per fare il run di un modulo direttamente in shell, ad esempiopython -m http.server
-B
per non scrivere il bytecode, utile in sviluppo, ma meglio usare la variabile d'ambientePYTHONDONTWRITEBYTECODE=true
Tra l'altro l'interprete è sufficientemente intelligente che se c'è un
.pyo
, questo sarà utilizzato anche in presenza di modifiche al file.py
originale, al contrario del.pyc
; si rende necessaria un'ulteriore compilazione in bytecode ottimizzato (oppure eliminare i.pyo
... ma si perderebbe l'ottimizzazione). Infatti, se non ci sono ottimizzazioni, l'interprete al primo giro creerà i.pyc
per poi utilizzarli sempre durante il lifecycle dell'applicazione. Nel caso di modifica del file.py
e reload del modulo, allora verrà ricreato il file.pyc
.Spero di aver riassunto bene. Questo genere di "complessità" a livello di interprete non mi sembra sia presente in Ruby, anche se totalmente trasparente allo sviluppatore.