Hallo,
ich habe mir Python 3.3 heruntergeladen und (unter Windows 7) ein Programm im Editor geschrieben, das ich nun gern ausprobieren würde, und habe das unter .py abgespeichert. Allerdings lässt sich das Programm nicht öffnen, beziehungsweise erscheint cmd nur für einen sehr kurzen Zeitraum, sodass man nicht lesen kann, was eigentlich passiert.
Kann mir jemand weiterhelfen?
Viele Grüße,
Geminio
Programm aus Editor öffnen
@Geminio: Starte das Programm in einer bereits offenen Eingabeaufforderung über die Kommandozeile. Dann geht die Eingabeaufforderung auch nicht zu nach dem das Programm beendet ist.
@Geminio: Schau mal in der Python-Dokumentation nach. Da steht irgendwo wie man Python-Programme unter den verschiedenen Betriebssystemen startet und welche Umgebungsvariablen und/oder Dateiverknüpfungen man dafür in Windows einrichten muss.
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
Alternativ, lies den Wiki Eintrag: http://wiki.python-forum.de/FAQ#Wie_sta ... Skripte.3F
P.S. Willkommen zu Python und zum Forum!
P.S. Willkommen zu Python und zum Forum!
Michael Markert ❖ PEP 8 Übersetzung ❖ Tutorial Übersetzung (3.x) ⇒ Online-Version (Python 3.3) ❖ Deutscher Python-Insider ❖ Projekte
Den Tipp halte ich für nicht besonders zielführend. Wenn man eine laufende Konsole haben möchte, dann sollte man sie vorher öffnen. Wenn nicht, nicht.Hellstorm hat geschrieben:Ein Tipp für Windows: Am Ende des Programms input() schreiben, dann bleibt das Fenster offen, bis man Enter drückt.
@Hellstorm: Wenn im Programm eine unbehandelte Ausnahme auftritt hat man wieder das selbe Problem. Und alle die Konsolenprogramme so starten wie man das eigentlich vorgesehen ist, ärgern sich jedes mal wenn sie am Ende völlig sinnloserweise noch mal die Eingabetaste betätigen müssen um zum Prompt zurück zu kehren.
Natürlich ist das nervig, wenn man das Programm dann aus einer laufenden Konsole startet. Allerdings ist es genauso nervig, wenn das Programmfenster wieder automatisch zugeht und man gar keine Rückmeldung über das Programmergebnis hat. Und immer manuell eine Konsole zu öffnen ist auch nervig.
Von daher muss man halt gucken, wann das passt. Dass das aus Prinzip nicht gut ist würde ich nicht sagen.
Von daher muss man halt gucken, wann das passt. Dass das aus Prinzip nicht gut ist würde ich nicht sagen.
@Hellstorm: Natürlich ist das aus Prinzip nicht gut. Konsolenprogramme sind für die Konsole. Wenn man die nicht in ihrer „natürlichen” Umgebung startet, dann macht man entweder etwas beim Ausführen falsch, oder man hätte eine GUI-Anwendung schreiben sollen. Und selbst *die* wird man zumindest solange man sie entwickelt immer in einer Konsole starten, denn dort landen wichtige Informationen die man zur Fehlersuche braucht. Denn in GUI-Toolkits brechen nicht mehr alle Ausnahmen das Programm ab, sondern die Tracebacks werden in der Regel auf der Konsole ausgegeben. Das will man als Programmierer sehen. Und Debug- oder Informations-Logausgaben kann man da auch prima ausgeben.
Viele Programmierer müssen auch nicht extra eine Konsole öffnen. Die ist schon offen. Mit einer interaktiven Python-Shell, für die Kommandozeilentools der Versionskontrolle, für SSH-Verbindungen zu Servern, und so weiter.
Viele Programmierer müssen auch nicht extra eine Konsole öffnen. Die ist schon offen. Mit einer interaktiven Python-Shell, für die Kommandozeilentools der Versionskontrolle, für SSH-Verbindungen zu Servern, und so weiter.
Aber wenn ich z.B. nur für mich ein Skript schreibe, was einfach nur eine relativ simple Aktion ausführt und wo ich keine Lust habe, eine GUI zu schreiben. Die könnte ich z.B. bei Windows in das Dateimenü, was bei einem rechten Mausklick aufgeht, einfügen (sagen wir mal „mehrere Dateien zusammenfügen“). Da öffne ich doch vorher keine Konsole, gehe umständlich in den entsprechenden Ordner, tippe den Programmnamen ein, nur damit ich nachher das Ergebnis sehen kann. Da mache ich das einfach nur durch einen Doppelklick o.ä. auf.BlackJack hat geschrieben:@Hellstorm: Natürlich ist das aus Prinzip nicht gut. Konsolenprogramme sind für die Konsole. Wenn man die nicht in ihrer „natürlichen” Umgebung startet, dann macht man entweder etwas beim Ausführen falsch, oder man hätte eine GUI-Anwendung schreiben sollen. Und selbst *die* wird man zumindest solange man sie entwickelt immer in einer Konsole starten, denn dort landen wichtige Informationen die man zur Fehlersuche braucht. Denn in GUI-Toolkits brechen nicht mehr alle Ausnahmen das Programm ab, sondern die Tracebacks werden in der Regel auf der Konsole ausgegeben. Das will man als Programmierer sehen. Und Debug- oder Informations-Logausgaben kann man da auch prima ausgeben.
Viele Programmierer müssen auch nicht extra eine Konsole öffnen. Die ist schon offen. Mit einer interaktiven Python-Shell, für die Kommandozeilentools der Versionskontrolle, für SSH-Verbindungen zu Servern, und so weiter.
Wieso sollte ich dann nicht für mich selber eine Methode wählen, dass das Fenster nachher offen bleibt? Wo ist da das Problem? Bei anderen Konsolenprogrammen, die man weiterverteilt (und die normalerweise eher für Linux, nicht so sehr für Windows sind) ist das natürlich was anderes, aber du kannst mir nicht sagen, dass es gar keinen Verwendungszweck für „halte das Fenster offen“ gibt.