Salve a tutti, io nella mia ignoranza con Windows (Python 3.8.2) x avviare un programma Python da dentro un programma Python utilizzo




os.startfile('Gui Dis.py')





lo stesso comando non funziona sotto Linux (Raspberry) , con Python 3.7.3 , mi dice che os non ha quel comando....




Come posso fare ??




Ho visto che se faccio un'import del file quando lo dovrei lanciare ... funziona , ma non mi sembra la soluzione migliore.




Grazie





--- Ultima modifica di trescon in data 2020-08-21 22:17:54 ---

Perché?

No so, a pelle mi sembrava la soluzione meno elegante ... poi non so.
Grazie

Si beh, questa è la solita confusione tra "programma" e "modulo". Un programma non è un modulo, un modulo non è un programma.


Un "programma" è un software che si intende completo e concluso, con una sua funzionalità, che si desidera avviare (e magari mantenere in esecuzione) in un thead di esecuzione suo specifico. Un "programma" può ovviamente dialogare con altri "programmi" in esecuzione parallela nella stessa sessione del sistema operativo, ci mancherebbe. Un "programma" può essere avviato da altri "programmi", ci mancherebbe. Tuttavia, se è un "programma", si suppone che abbia una ragion d'essere sua propria, una sua propria autonomia, un motivo per cui il sistema operativo dovrebbe eseguirlo.


Un "modulo" (o molti moduli che lavorano insieme: una "libreria", come si dice) è un pezzo di software fatto per essere utilizzato all'interno di altro software (di altri moduli, di altre librerie o, infine, di altri "programmi"), nello stesso thread di esecuzione (o comunque dello stesso processo, in caso di software multi-threading). Un modulo talvolta può essere eseguito autonomamente come se fosse un programma, ci mancherebbe. Ma la sua vocazione è quella di essere... sorpresa... importato da altri moduli.





Quindi, se quello che hai in mano è un PROGRAMMA (che sia scritto in python, in lua, in java, in c++, in brainfuck non importa) e vuoi eseguirlo dall'interno del tuo software, tipicamente quello che vuoi fare è avviarlo con subprocess (e NON certamente con accrocchi terrificanti in stile tutorial html.it, come os.startfile) ed eventualmente poi comunicare con il suo processo, con le primitive che subprocess mette a disposizione (e se il processo ha qualcosa di interessante da comunicare, beninteso).


Se invece quello che hai in mano è un MODULO, e vuoi utilizzarne le funzionalità all'interno del tuo codice, allora devi importarlo, e leggerti la sua documentazione e usare la sua api nel tuo codice.


In sintesi, questo è. "Elegante", "meno elegante", e "la pelle" c'entrano pochino.

Grazie Ricpol per la risposta... ma a parte l’orribilita’ della forma mi sai dire come mai il comando Python os.startfile funziona “sotto” window ma non sotto Linux.
Grazie

Lo dice molto chiaramente la documentazione, che indica "Availability: Windows", sotto linux semplicemente non è disponibile

Python 3.6.9 (default, Jul 17 2020, 12:50:27) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license()" for more information.
>>> import os
>>> help('os.startfile')
No Python documentation found for 'os.startfile'.
Use help() to get the interactive help utility.
Use help(str) for help on the str class.

>>> from os import startfile
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    from os import startfile
ImportError: cannot import name 'startfile'
>>> 

Pertanto, dovresti utilizzare altre mezzi sotto linux, tipo "subprocess" o "os.popen()", etc., utilizzando comandi o accorgimenti propri di linux, per eseguirli (tipo shebang, permessi esecuzione, etc.).


--- Ultima modifica di nuzzopippo in data 2020-08-23 08:13:51 ---

--- Ultima modifica di nuzzopippo in data 2020-08-23 08:16:18 ---

Grazie per i chiarimenti , io ero partito dall’affermazione letta in più di qualche manuale in cui si diceva che Python era trasparente e i programmi erano portatili rispetto alla piattaforma software (windows, linux,..) sulla quale girava python.
Invece questo non è vero (sempre vero); che mi serva di lezione visto che lavoro (😱😇) su entrambe le piattaforme. (Vero che il comando usato non è proprio il più adatto però sta di fatto che il programma su Linux non va).




Grazie a tutti per i chiarimenti, anche stavolta un IGNORANTE ha imparato qualcosa.

Ma vorrei veramente vederlo, un manuale serio che fa un'affermazione del genere... capirei il corso della domenica su YT, ma... Oddio, non è che mi stupisco più di molto ormai.


Ovviamente Python (come Java, etc) cerca di essere "crosspiattaforma", ma altrettanto ovviamente le "piattaforme" su cui si trova a lavorare sono diverse, e fanno le cose in modo diverso. E certe cose non possono essere fatte da Python, devono essere delegate al sistema operativo sottostante... le operazioni con il file system, per esempio. Una path su windows è una cosa diversa da una path su linux, e anche se il modulo pathlib cerca di offrire un minimo terreno comune, resta il fatto che certe specifiche cose su windows le puoi fare, su linux no (e viceversa). L'alternativa sarebbe limitare il set di funzionalità a un minimo inservibile per tutti.

La documentazione di moduli come os, sys, pathlib... è costellata di notazioni "availability: windows/linux" eccetera. Non può essere altrimenti. Molte cose poi non sono neanche molto documentate: per esempio, in windows se fai banalmente una cosa come

>>> import os
>>> f = open('miofile')
>>> os.remove('miofile')

ti becchi un errore. In Linux no. Perché? Perché in windows aprire un file (anche in sola lettura) crea un lock. E' semplicemente che il sistema operativo funziona in modo diverso. Che cosa vogliamo fare, togliere la possibilità di aprire un file con Python, in modo da rimanere "crosspiattaforma"?




La verità è che non puoi sperare che Python ti esenti dalla faticaccia di studiare e capire, almeno un po', anche come funziona il suo ambiente di esecuzione (file system, sistema operativo, etc.). Questa cosa si chiama Law of the Leaking Abstractions. Nella sua formulazione originale, Joel Spolsky fa un ottimo lavoro per spiegare che cosa significa davvero "astrazione" in informatica. Una astrazione è "un modo semplice di usare una cosa complicata sottostante, a patto di aver capito come funziona la cosa complicata sottostante". Di solito uno pensa invece che "astrazione" significa "un modo semplice di usare una cosa complicata senza bisogno di capirla". Il motivo per cui tutti ormai oggi fanno questo tipo di confusione è complesso e dipende da molte cose che sono successe nel passato. Ne parlo (tra molte altre cose) anche qui https://pythoninwindows.blogspot.com/2020/03/come-imparare-python-senza-studiare.html





Allo stesso modo, non basta aver visto in giro qualcuno che usava "os.startfile" per aprire un file, per usare "os.startfile" assumendo che funzioni e basta. Bisogna anche aprire la documentazione di "os.startfile", leggere la documentazione di "os.startfile", capire che cosa fa davvero "os.startfile", e solo a quel punto, eventualmente, usare "os.startfile".
Ora, "os.startfile" è solo un wrapper che invoca la funzione "ShellExecuteEx" del sistema operativo... ShellExecuteEx è la funzione che, dietro le quinte, windows utilizza ogni volta che si fa doppio clic sull'icona di un file, per esempio. Ha una euristica tutta sua particolare, che decide che cosa bisogna fare a seconda del file. Se è un file eseguibile (un programma) allora lo esegue, altrimenti cerca di individuare il programma più adatto per "aprire" il file, in base alle estensioni e alle associazioni. E' il motivo per cui se fai doppio clic su un file ".doc", ti si apre Word.


Quindi, in python puoi fare "os.startfile('miofile.doc')" e avviare Word, o qualsiasi altro programma Windows abbia associato ai file ".doc" su quella macchina. Naturalmente è una bella comodità, ed è carino che Python metta a disposizione "os.startfile"... su Windows! Perché ShellExecuteEx su Linux ovviamente non esiste, e non esiste nessuna funzione del sistema operativo che faccia una cosa del genere.


Tutto questo... è documentato.

Grazie Ricpol, come il solito molto esauriente.
Il mio problema (inteso come personale) è che mastico poco l’inglese, quindi trovo la documentazione “difficile da capire” con Google translate.

Per questo cerco di imparare Python con l’esperienza che mi faccio ogni volta che devo fare un “progetto” con un comando nuovo....quindi molte cose mi sono ignote.

Poi ,non so se sia il problema solo mio , ma trovo la documentazione di Python molto contorta e complicata da capire ( per esempio, sarebbe chiedere troppo se quando spiega/illustra un comando fa un banale esempio di come si applica?)

E poi forse sono troppo DURO a capire causa l’età proprio non giovanissima.

Comunque grazie ancora per le spiegazioni, vedrò di farne tesoro..... e farò sicuramente ancora molte domande stupide 😇

Il mio intento era , per motivi di presunta incapacità’ assembrativa, di avere un’interfaccia semplice con una serie di Button che permette di avviare 5/6 procedure.py che vanno eseguite in ordine sequenziale. (Che per motivi di test ho sviluppato singolarmente)
Quindi mi consigliate subprocess.... proverò ....

Grazie