pythonw.exe oder python.exe?

156

Um es kurz zu machen: pythonw.exe tut nichts, python.exeakzeptiert nichts (welches soll ich verwenden?)

test.py:

print "a"

CMD-Fenster:

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>

Bitte sag mir, was ich schrecklich falsch mache.

python python-3.x

— es funktioniert nicht
quelle

14

Leider vermischt dies die beiden Aspekte Python vs Pythonw (im Allgemeinen der interessantere Aspekt) und einige grundlegende Syntaxänderungen von Python2 zu Python3. keine Kritik an der OP , die nicht vorher wissen konnte, aber dennoch verdirbt es den Wert dieser Frage als die Go-to - Ressource über Python w .

— Mnagel

170

Wenn beim Ausführen Ihres Programms kein Terminalfenster angezeigt werden soll, verwenden Sie pythonw.exe;
Andernfalls verwenden Siepython.exe

In Bezug auf den Syntaxfehler: print ist jetzt eine Funktion in 3.x
Verwenden Sie stattdessen:

print("a")

— mechanisches Fleisch
quelle

282

Um die vorhandenen Antworten zusammenzufassen und zu ergänzen:

python.exeist eine Konsolenanwendung (Terminal) zum Starten von CLI-Skripten .
- Öffnet python.exe ein neues Konsolenfenster , sofern es nicht über ein vorhandenes Konsolenfenster ausgeführt wird .
- Standard - Streams sys.stdin , sys.stdoutund sys.stderrsind in das Konsolenfenster verbunden .
- Die Ausführung ist synchron, wenn sie über ein cmd.exeoder ein PowerShell-Konsolenfenster gestartet wird : ^{Siehe den ersten Kommentar von eryksun unten.}
  - Wenn ein neues Konsolenfenster erstellt wurde, bleibt es geöffnet, bis das Skript beendet wird.
  - Beim Aufrufen über ein vorhandenes Konsolenfenster wird die Eingabeaufforderung blockiert, bis das Skript beendet wird.
pythonw.exeist eine GUI-App zum Starten von GUI / No-UI-at-All-Skripten .
- Es wird KEIN Konsolenfenster geöffnet.
- Die Ausführung erfolgt asynchron :
  - Beim Aufrufen über ein Konsolenfenster wird das Skript lediglich gestartet und die Eingabeaufforderung wird sofort zurückgegeben, unabhängig davon, ob das Skript noch ausgeführt wird oder nicht.
- Standard - Streams sys.stdin , sys.stdoutund sys.stderrsind NICHT vorhanden .
  - Achtung : Wenn Sie keine zusätzlichen Schritte unternehmen , hat dies möglicherweise unerwartete Nebenwirkungen :
    - Unbehandelte Ausnahmen führen das Skript abbrechen still .
    - In Python 2.x kann der einfache Versuch, dies zu verwenden print(), dazu führen (in 3.x hat dies print()einfach keine Auswirkung).
    - Um dies in Ihrem Skript zu verhindern und mehr zu erfahren, lesen Sie meine Antwort .
    - Ad-hoc können Sie die Ausgabeumleitung verwenden : ^{Danke, @handle.}
      pythonw.exe yourScript.pyw 1>stdout.txt 2>stderr.txt
      (von PowerShell :)
      cmd /c pythonw.exe yourScript.pyw 1>stdout.txt 2>stderr.txtzum Erfassen der Ausgabe von stdout und stderr in Dateien .
      Wenn Sie sicher sind, dass die Verwendung von print()der einzige Grund ist, mit dem Ihr Skript unbemerkt fehlschlägt pythonw.exe, und Sie nicht an der Ausgabe von stdout interessiert sind, verwenden Sie den Befehl @ handle aus den Kommentaren:
      pythonw.exe yourScript.pyw 1>NUL 2>&1
      Vorsichtsmaßnahme : Diese Ausgabeumleitungsmethode funktioniert nicht , wenn Sie *.pywSkripte direkt aufrufen ( im Gegensatz zum Übergeben des Skriptdateipfads an pythonw.exe). ^{Siehe den zweiten Kommentar von eryksun und seine Folgemaßnahmen weiter unten.}

Sie können steuern, welche der ausführbaren Dateien Ihr Skript standardmäßig ausführt - beispielsweise beim Öffnen im Explorer -, indem Sie die richtige Dateinamenerweiterung auswählen :

*.py Dateien werden standardmäßig zugeordnet (aufgerufen) python.exe
*.pyw Dateien werden standardmäßig zugeordnet (aufgerufen) pythonw.exe

— mklement0
quelle

1

PS: Es funktioniert, wenn ich irgendwo stdout und stderr pfeife: > pythonw ls.pyw >nul 2>&1(obwohl nichts geschrieben ist).

— behandeln

1

Dieses synchrone und asynchrone Verhalten erfolgt nur über die interaktive Eingabeaufforderung cmd.exe, ohne den startBefehl zu verwenden. Es überprüft tatsächlich den untergeordneten PEBProzess, um festzustellen, ob es sich um einen Konsolenprozess handelt. Der Konsolenhostprozess (conhost.exe) kümmert sich nicht darum. Wenn Sie eine subprocess.Popenandere python.exeInstanz an die aktuelle Konsole anhängen und diese nicht verwenden wait, werden beide Prozesse verwirrend durcheinander geraten, um gleichzeitig auf die Konsole zuzugreifen.

— Eryk Sun

2

Durch den Systemaufruf wird ein Benutzermodusprozess erstellt NtCreateUserProcess. Wenn die ausführbare Zieldatei ein Konsolenprogramm ist, erbt das System bedingungslos die Standardhandles des übergeordneten Elements. Für ein Nicht-Konsolenprogramm muss jedoch ausdrücklich angewiesen werden, die vererbbaren Handles der Eltern zu erben. Um eine Datei basierend auf einer Dateizuordnung auszuführen, ruft cmd auf ShellExecuteEx, die beim Aufrufen nicht explizit Handles erbt CreateProcess=> NtCreateUserProcess. Folglich funktioniert das Umleiten von Standard-E / A in cmd, wenn Konsolen-.py-Skripte gestartet werden, jedoch keine Nicht-Konsolen-.pyw-Skripte.

— Eryk Sun

2

Die cmd-Shell versucht zunächst CreateProcessmit bInheritHandlesübergeben als TRUE. Es greift nur dann zurück, ShellExecuteExwenn CreateProcessein Fehler auftritt, da das Ziel keine ausführbare PE-Datei ist (z. B. ein .py-Skript) oder eine Erhöhung erfordert (z. B. osk.exe). Also , wenn Sie direkt ausführen pythonw.exeoder pyw.exewird es CMDs erben StandardInput, StandardOutputund StandardError, was cmd (eigentlich die CRT) modifiziert über SetStdHandlevor und nach dem Aufruf , CreateProcesswenn Standard - I / O zu einem Rohr umgeleitet wird, eine Datei oder Gerät.

— Eryk Sun

2

Beachten Sie, dass STARTUPINFOcmd im Gegensatz zu Python nicht die Handles (hStdInput, hStdOutput, hStdErr) verwendet subprocess.Popen. Es kann damit durchkommen, weil es ein Single-Thread-Programm ist. Nur aufgrund dieses Designs funktioniert die Umleitung überhaupt ShellExecuteEx(wie bereits erwähnt, nur für Konsolenprogramme), da die GUI-Shell-API ansonsten keine Unterstützung für Standard-E / A bietet.

— Eryk Sun

19

Siehe hier: http://docs.python.org/using/windows.html

pythonw.exe "Dies unterdrückt das Terminalfenster beim Start."

— jon
quelle

8

pythonw.exehat Nebenwirkungen, dass Ihr Programm möglicherweise stillschweigend fehlschlägt, wenn es in stdout / stderr stream schreibt - siehe bugs.python.org/issue706263

— anatoly techtonik

16

Wenn Sie ein Python-Skript aus einem anderen Prozess (z. B. über die Befehlszeile) aufrufen möchten, verwenden Sie pythonw.exe. Andernfalls wird Ihrem Benutzer ständig ein cmdFenster angezeigt, in dem der Python-Prozess gestartet wird. Ihr Skript wird trotzdem ausgeführt, die Benutzererfahrung wird jedoch nicht beeinträchtigt.

Ein Beispiel könnte das Senden einer E-Mail sein. python.exeöffnet ein CLI-Fenster, sendet die E-Mail und schließt das Fenster. Es erscheint als schneller Blitz und kann als etwas nervig angesehen werden. pythonw.exevermeidet dies, sendet aber trotzdem die E-Mail.

— Droogans
quelle

6

Das stimmt, aber re „sagen wir, von der Kommandozeile“: Wenn Sie bereits sind in einer Konsole (Terminal) Fenster, dann python.exewird nicht eine andere öffnen.

— mklement0

2

Ich hatte eine Weile Mühe, dies zum Laufen zu bringen. Stellen Sie nach dem Ändern der Erweiterung in .pyw sicher, dass Sie die Eigenschaften der Datei öffnen und den Pfad "Öffnen mit" zu pythonw.exe leiten.

— Ngula
quelle

-4

Nach meiner Erfahrung ist pythonw.exe zumindest mit Pygame schneller.

— Lenart Svetek
quelle