pythonw.exe o python.exe?

157

Per farla breve: pythonw.exenon fa nulla, non python.exeaccetta nulla (quale dovrei usare?)

test.py:

print "a"

Finestra CMD:

C:\path>pythonw.exe test.py
<BLANK LINE>
C:\path>

C:\path>python.exe test.py
  File "C:\path\test.py", line 7
    print "a"
            ^
SyntaxError: invalid syntax

C:\path>

Per favore, dimmi cosa sto facendo di terribilmente sbagliato.

python python-3.x

— itdoesntwork
fonte

14

sfortunatamente questo mescola i due aspetti python vs pythonw (generalmente l'aspetto più interessante) e alcune modifiche di sintassi di base da python2 a python3. nessuna critica del PO che non poteva sapere in anticipo, ma comunque contamina il valore di questa domanda, come il go-to risorsa su Python w .

— mnagel,

170

Se non si desidera che venga visualizzata una finestra di terminale quando si esegue il programma, utilizzare pythonw.exe;
Altrimenti, usapython.exe

Per quanto riguarda l'errore di sintassi: print ora è una funzione in 3.x
Quindi utilizzare invece:

print("a")

— mechanical_meat
fonte

283

Per riassumere e integrare le risposte esistenti:

python.exeè un'applicazione console (terminale) per l'avvio di script di tipo CLI .
- A meno che non venga eseguito da una finestra della console esistente, python.exe apre una nuova finestra della console .
- Flussi standard sys.stdin , sys.stdoute sys.stderrsono collegato alla finestra della console .
- L'esecuzione è sincrona se avviata da una cmd.exefinestra della console di PowerShell: ^{vedere il primo commento di eryksun di seguito.}
  - Se è stata creata una nuova finestra della console, questa rimane aperta fino al termine dello script.
  - Quando viene richiamato da una finestra della console esistente, il prompt viene bloccato fino al termine dello script.
pythonw.exeè un'app GUI per l'avvio di script GUI / no-UI-at-all .
- Non viene aperta la finestra della console .
- L'esecuzione è asincrona :
  - Quando viene richiamato da una finestra della console, lo script viene semplicemente avviato e il prompt torna immediatamente, indipendentemente dal fatto che lo script sia ancora in esecuzione o meno.
- Flussi standard sys.stdin , sys.stdoute sys.stderrsono non disponibili .
  - Attenzione : a meno che non si eseguano ulteriori passaggi , questo ha effetti collaterali potenzialmente inattesi :
    - Eccezioni non gestite causano l' interruzione silenziosa dello script .
    - In Python 2.x, il semplice tentativo di utilizzo print()può causare che ciò accada (in 3.x, print()semplicemente non ha alcun effetto).
    - Per evitarlo dall'interno della tua sceneggiatura e per saperne di più, vedi questa mia risposta .
    - Ad-hoc , è possibile utilizzare il reindirizzamento dell'output :^{grazie, @handle.}
      pythonw.exe yourScript.pyw 1>stdout.txt 2>stderr.txt
      (da PowerShell:)
      cmd /c pythonw.exe yourScript.pyw 1>stdout.txt 2>stderr.txtper acquisire l'output di stdout e stderr nei file .
      Se sei sicuro che l'uso di print()è l'unico motivo per cui lo script non riesce in modo silenzioso pythonw.exee non sei interessato all'output stdout, usa il comando @ handle dai commenti:
      pythonw.exe yourScript.pyw 1>NUL 2>&1
      Avvertenza : questa tecnica di reindirizzamento dell'output non funziona quando si invocano direttamente gli*.pyw script ( al contrario, passando il percorso del file di script a ). ^Vedi^{il secondo commento di}^eryksun^{e i suoi follow-up di seguito.}pythonw.exe

Puoi controllare quale degli eseguibili esegue lo script per impostazione predefinita , ad esempio quando viene aperto da Explorer, scegliendo l'estensione del nome file corretta :

*.py i file sono per impostazione predefinita associati (invocati) a python.exe
*.pyw i file sono per impostazione predefinita associati (invocati) a pythonw.exe

— mklement0
fonte

1

PS: Funziona quando installo stdout e stderr da qualche parte: > pythonw ls.pyw >nul 2>&1(anche se non è scritto nulla).

— gestire

1

Questo comportamento sincrono e asincrono proviene semplicemente dal prompt dei comandi interattivo cmd.exe senza utilizzare il startcomando. Ispeziona effettivamente il PEBprocesso figlio per determinare se si tratta di un processo console. Il processo host della console (conhost.exe) non si preoccupa di questo. Se usi subprocess.Popenper collegare un'altra python.exeistanza alla console corrente e non waitsu di essa, allora avrai un pasticcio confuso di entrambi i processi che corrono per accedere alla console contemporaneamente.

— Eryk Sun,

2

Un processo in modalità utente viene creato dalla chiamata di sistema NtCreateUserProcess. Se l'eseguibile di destinazione è un programma console, il sistema eredita incondizionatamente gli handle standard del genitore. Ma per un programma non console richiede che venga esplicitamente detto di ereditare gli handle ereditabili del genitore. Per eseguire un file basato su un'associazione di file, cmd chiama ShellExecuteEx, che non eredita esplicitamente gli handle quando chiama CreateProcess=> NtCreateUserProcess. Di conseguenza, il reindirizzamento dell'I / O standard funziona in cmd all'avvio degli script .py della console ma non degli script .pyw non della console.

— Eryk Sun,

2

La shell cmd prima prova CreateProcesscon bInheritHandlespassato come TRUE. Si ripete solo ShellExecuteExquando CreateProcessfallisce perché la destinazione non è un eseguibile PE (ad es. È uno script .py) o richiede elevazione (ad es. Osk.exe). Quindi, quando si esegue direttamente pythonw.exeo pyw.exe, esso erediterà del cmd StandardInput, StandardOutpute StandardError, che CMD (in realtà la CRT) modifica via SetStdHandleprima e dopo la chiamata CreateProcessquando standard di I / O viene reindirizzato ad un tubo, un file o dispositivo.

— Eryk Sun,

2

Si noti che cmd non utilizza gli STARTUPINFOhandle (hStdInput, hStdOutput, hStdErr), a differenza di Python subprocess.Popen. Può cavarsela perché è un programma a thread singolo. È solo grazie a questo design che il reindirizzamento funziona affatto ShellExecuteEx(solo per i programmi console, come notato) perché l'API della shell della GUI non ha alcun supporto per l'I / O standard.

— Eryk Sun,

19

Vedi qui: http://docs.python.org/using/windows.html

pythonw.exe "Questo elimina la finestra del terminale all'avvio."

— jon
fonte

8

pythonw.exeha effetti collaterali che il tuo programma potrebbe fallire silenziosamente se scrive su stream stdout / stderr - vedi bugs.python.org/issue706263

— anatoly techtonik

16

Se hai intenzione di chiamare uno script Python da qualche altro processo (diciamo, dalla riga di comando), usa pythonw.exe. Altrimenti, il tuo utente vedrà continuamente acmd finestra che avvia il processo Python. Eseguirà comunque lo stesso script, ma non interferirà con l'esperienza dell'utente.

Un esempio potrebbe essere l'invio di un'e-mail; python.exeaprirà una finestra della CLI, invierà l'e-mail, quindi chiuderà la finestra. Apparirà come un lampo rapido e può essere considerato un po 'fastidioso. pythonw.exeevita questo, ma invia comunque l'e-mail.

— Droogans
fonte

6

True "per esempio, dalla riga di comando", ma re: Se già siete in una finestra di console (terminale), quindi python.exesi non aprire un altro.

— mklement0

2

Stavo lottando per farlo funzionare per un po '. Dopo aver modificato l'estensione in .pyw, assicurati di aprire le proprietà del file e di indirizzare il percorso "Apri con" a pythonw.exe.

— Ngula
fonte

-4

Nella mia esperienza il pythonw.exe è più veloce almeno con l'utilizzo di pygame.

— Lenart Svetek
fonte