824895_it-IT

liliconcom

Fornire un meccanismo di riavvio del kernel Python

Cosa ti ha ispirato a richiedere questa lista dei desideri?

Lo sviluppo di codice Python da eseguire in JMP in genere comporta la clonazione di un repository Github e l'indirizzamento di JMP alla copia locale del codice come segue:

jmputils.jpip('install','myrepo c:\\pathto\\myrepo')

Quale miglioramento vorresti vedere?

Fornire un meccanismo (pulsante, API, ??) che consenta all'utente di riavviare il kernel Python senza dover chiudere e riaprire JMP.

Perché questa idea è importante?

Durante lo sviluppo del codice, ci sono numerose modifiche al codice locale, ognuna delle quali richiede che il nuovo codice venga caricato nel kernel Python. Attualmente, l'unico modo per caricare il nuovo codice locale nel kernel Python è chiudere e riavviare JMP. Ciò rallenta notevolmente lo sviluppo e potrebbe rappresentare un ostacolo per alcuni sviluppatori.

Automazione e scriptingRe: Fornire un meccanismo di riavvio del kernel Python

Il primo codice modificato nell'editor e rieseguito viene eseguito con le modifiche.

Se è un codice che hai importato

importa il mio codice

# quando è necessario forzare il ricaricamento del pacchetto 'mycode'

importare importalib

importlib.reload(miocodice)

Questo è il comportamento Python esistente. Nella maggior parte dei casi non si vede questo comportamento perché Python viene eseguito dalla riga di comando e lo script e Python escono tra le esecuzioni. Poiché JMP carica la libreria condivisa Python, in questi casi bisogna pensare a JMP come Python. Se si dovesse fare lo stesso lavoro all'interno della console interattiva Python (ad esempio IDLE), senza uscire tra le modifiche, si vedrebbe lo stesso comportamento. L'ambiente Python rimane attivo dal primo utilizzo fino all'uscita di JMP perché l'ambiente è condiviso. È così che l' integrazione JSL/Python può essere implementata.

Quindi no, al momento non forniremo un "riavvio", poiché il pacchetto importlib.reload( ) soddisfa questa esigenza.

Stiamo studiando la possibilità di lanciare sub-interpreti Python indipendenti. Ciò consentirebbe molte funzionalità aggiuntive, come l'esecuzione di uno script in un ambiente pulito(er) quando necessario. L'indagine sui sub-interpreti è uno dei motivi per cui JMP 19 passa a Python 3.13.x. Gli aggiornamenti e il ciclo di vita della sicurezza sono il driver principale dell'aggiornamento a 3.13.x

Re: Fornire un meccanismo di riavvio del kernel Python - Stato modificato in: Non pianificato per oraRe: Fornire un meccanismo di riavvio del kernel Python

Hm. Mi piace la possibilità di condividere tutte le mie variabili tra diverse finestre di script Python e attività in background.
Avrei voluto che Application Builder avesse questa opzione!

Ma devo ammettere che sembra un po' "sperimentale".
Ci siamo abituati a reimpostare il kernel tramite un riavvio, fin dal 1995: è davvero comodo.
Molti altri (!!!) IDE Python forniscono questa funzionalità: altri eseguono il codice e poi chiudono il kernel.

"eseguire uno script in un ambiente più pulito"
...sembra promettente.

Immagino che l'avvio (e il riavvio) di tali sottointerpreti sia quindi disponibile automaticamente .
Mi chiedo perché "no". Questo ci fornisce la funzionalità che ci manca in JMP?

Re: Fornire un meccanismo di riavvio del kernel Python

Il problema più grande è che una libreria condivisa caricata in memoria non può essere scaricata dal processo in esecuzione. Questo non vale solo per Python stesso, ma anche per i pacchetti Python importati che hanno una libreria condivisa come NumPy. Python non è in esecuzione in un altro spazio di processo, ma all'interno e come parte di JMP stesso. Sì, Py_Finalize() può essere chiamato e Py_Initialize() successivo per inizializzare l'interprete una seconda volta. Il problema che ho riscontrato in passato è stato che NumPy non reagiva particolarmente bene all'importazione dopo la seconda inizializzazione dell'interprete. JMP è diventato instabile e incline a bloccarsi, specialmente durante l'importazione di NumPy dopo il riavvio. Non ho esaminato il modo in cui gli altri IDE gestiscono Python, ma potrebbero benissimo eseguire un'istanza di Python invece di incorporare Python.

Abbiamo ripulito parecchio la gestione della memoria in JMP 18 rispetto alle versioni precedenti, quindi potrebbe valere la pena di rivisitarlo per vedere se un riavvio del genere è fattibile. Potrebbe essere stata la nostra gestione della memoria o potrebbe essere ancora un problema con NumPy e altri pacchetti che caricano librerie condivise.