SCITE Problem F5

[pitwo]

Hallo Leute,

a.py :

Code: Alles auswählen

guess = input("Raten Sie: ")

Wenn ich das in der Konsole mit "python -u a.py" ausführe, klappt alles ohne Probleme.

Wenn ich den gleichen Quelltext jedoch in SciTE mit F5 aufrufe, kommt folgende Fehlermeldung:

>python -u "a.py"
Raten Sie: Traceback (most recent call last):
File "a.py", line 1, in <module>
guess = raw_input("Raten Sie: ")
IOError: [Errno 9] Bad file descriptor
>Exit code: 1

Kann mir bitte jemand bei diesem Problemchen helfen?

Die selbe Frage wurde vor einem Jahr schon auf diesem Forum gestellt aber ich habe die Lösung nicht gefunden. Danke fûr die Antworten.

[numerix]

Die selbe Frage wurde vor einem Jahr schon auf diesem Forum gestellt aber ich habe die Lösung nicht gefunden. Danke fûr die Antworten.

Die Antwort ist einfach: Es gibt keine Lösung. Auch die aktuellste SciTE-Version zeigt unter Linux dieses Verhalten, unter Windows funktioniert das. Es scheint auch kaum jemanden ernsthaft zu stören (außer vielleicht dich und mich), denn man findet so gut wie nichts dazu.

Edit: Also, es gibt natürlich schon eine Lösung, aber nicht für den integrierten Ausgabebereich von SciTE. Du kannst SciTE z.B. so konfigurieren, dass du über einen anderen Shortcut als F5 den Quelltext in einem Extra-Terminal mittels Python ausführen lässt. Da funktioniert dann auch die Eingabe.

[Dauerbaustelle]

Empfehle Geany, hat auch Scintilla als Editor und noch viele andere schöne Features :)

[pitwo]

Die Antwort ist einfach

Fûr meinen ersten Besuch auf diesem Forum habe ich wirklich viel Glück :
- zuerst habe ich die Frage die ganz genau meinen Problem beschreibt hier gefunden, und das ist schon eine grosse "Chance" wenn man nur mit vieler Mühe Deutsch schreiben kann ;
- die Antwort, schnell gekommen, ist einfach : wenn es keine Lösung gibt werde ich sie nicht stundenlang suchen !

Also, es gibt natürlich schon eine Lösung, aber nicht für den integrierten Ausgabebereich von SciTE. Du kannst SciTE z.B. so konfigurieren, dass du über einen anderen Shortcut als F5 den Quelltext in einem Extra-Terminal mittels Python ausführen lässt. Da funktioniert dann auch die Eingabe.

Als Einsteiger habe ich noch viel zu lernen... Danke schön.

Noch ein kleine Frage : SciTE erkennt die Wörter wie "print", "if", "import", u.s.w. und wechselt die Farbe wenn man sie schreibt, aber bei mir geht es nicht so mit dem Wort "input" !? :K

[cofi]

Auch das ist einfach `if', `import' und (noch) `print' sind Statements. input - das man vor Python 3 nicht benutzen sollte - ist dagegen eine Funktion.

[numerix]

Noch ein kleine Frage : SciTE erkennt die Wörter wie "print", "if", "import", u.s.w. und wechselt die Farbe wenn man sie schreibt, aber bei mir geht es nicht so mit dem Wort "input" !? :K

Die erstgenannten sind Python-Schlüsselwörter, input() ist "lediglich" eine Funktion, die z.B. auch überschrieben werden kann.

Code: Alles auswählen

>>> print = 5
  File "<stdin>", line 1
    print = 5
          ^
SyntaxError: invalid syntax
>>> input = 5
>>> 

In Python 3.0 ist print() auch "nur" noch eine Funktion:

Code: Alles auswählen

>>> print = 5
>>>     

[numerix]

Auch das ist einfach `if', `import' und (noch) `print' sind Statements.

Das ist nicht das Entscheidende.

Python 2.5:

Code: Alles auswählen

>>> True = 5
>>> 

Python 3.0

Code: Alles auswählen

>>> True = 5
  File "<stdin>", line 1
SyntaxError: assignment to keyword

[pitwo]

Alles klar !

[Leonidas]

Also zusammengefasst: der Autor hat entschieden Statements (und auch andere Sachen) farblich hervorzuheben und irgendwelche anderen Sachen nicht. Das ist alles. Andere Highlighter machen das ggf. anders.

Zu dem Problem: ich führe Programme generell in einer eigenen Konsole aus, obwohl ich sie vom Editor starten könnte. Aber das funktioniert nur mit Programmen ohne Parametern einfach, wenn es ein Modul ist und das Programm über ein anderes Modul gestartet wird, hilft das sowieso nicht sonderlich weiter. Da habe ich schneller auf die Konsole gewechselt und den letzten Befehl wiederholt, als dass ich dem Editor sage, was er (mit welchen Parametern) starten soll.

[pitwo]

Empfehle Geany, hat auch Scintilla als Editor und noch viele andere schöne Features

Sehr schön und scheint wirklich einfach zu sein ! Für ein Einsteiger wie ich, das Ideale ?
Danke schön.

[C4S3]

Ich mag persönlich DrPython (http://drpython.sourceforge.net/) recht gerne. Einsteigerfreundlich, erweiterbar, toll!

[HerrHagen]

Wie wärs mit IDLE? Noch einsteigerfreundlicher, noch einfacher - noch besser

[cofi]

noch besser

Das will ich bezweifeln, aber bevor hier noch jemand seinen Lieblingseditor anpreist - btw benutze Vim! - hier der Thread in dem zahlreiche zu finden sind: http://www.python-forum.de/topic-3544.html

[DasIch]

btw benutze Vim!

Eine gute Entscheidung

Von Idle ist im übrigen abzuraten, löst mitunter recht seltsame Probleme, vorallem wenn man Tkinter nutzt, aus.

[numerix]

btw benutze Vim!

Eine gute Entscheidung

Von Idle ist im übrigen abzuraten, löst mitunter recht seltsame Probleme, vorallem wenn man Tkinter nutzt, aus.

Das musste ja wieder kommen. Ich habe bislang keinen Beleg dafür gefunden, dass es mit aktuellen IDLE-Versionen und korrektem Pythoncode inkl. Tkinter irgendein Problem gibt.

Gib doch mal ein Beispiel an, das außerhalb von IDLE läuft, mit IDLE aber nicht läuft, obwohl es korrekter Code ist.

[DasIch]

Eine Forensuche nach Idle liefert auf der ersten Seite schon mindestens einen Thread mit Code bei dem Idle (kommentarlos) abstürzt. Ende November sollte doch wohl aktuell genug sein?

[numerix]

Eine Forensuche nach Idle liefert auf der ersten Seite schon mindestens einen Thread mit Code bei dem Idle (kommentarlos) abstürzt. Ende November sollte doch wohl aktuell genug sein?

Der Beleg ist nichts Wert. Der Anwender weiß nicht, wie er IDLE richtig zu bedienen hat. Das beschriebene Verhalten ist genau das, was sich in dem anderen mir bekannten Thread zum "bösen IDLE" auch findet und leicht erklärbar ist (dort habe ich schon einen Post dazu geschrieben): Startet man IDLE ohne Subprozess (und das ist hier offenbar der Fall gewesen), merkt sich IDLE alle Importe etc., so lange man es nicht komplett schließt und neu startet. Startet man IDLE mit Subprozess, ist das nicht so. Das ist kein Bug, sondern definiertes Verhalten von IDLE. Wird - so weit ich mich erinnere - in der IDLE-Doku auch drauf hingewiesen.

Also: Ich warte weiter auf ein Beispiel ...
(Im übrigen hattest du speziell auf Probleme mit Tkinter hingewiesen, was im von dir zitierten Thread ja ohnehin nicht der Fall ist.)

[BlackVivi]

Tkinter wird wohl nicht soviele Probleme machen, weil's ja selber in Tkinter geschrieben ist. Aber GUI-Programmierung in anderen Toolkits verursacht 100% merkwürdiges Verhalten. Das habe ich bei wx, QT und auch bei anderen Bibliotheken wie numpy + plotten beobachtet. Jedoch ist das kein unbedingtes Problem von tkinter, sondern allgemein von allen shells. Ipython fühlt sich mich Gui-Programmierung auch ein wenig komisch an, wenn man mal etwas ausprobieren will (jedoch gibts da schöne Kommandozeilenargumente die irgendwas mit den Threads machen, dass sich das ganze nicht in die Quere kommt)

Das merkwürdige Verhalten lässt sich ganz einfach erklären - der Mainthread von Tkinter und andere Threads kommen sich bös in die Quere. Wie Gui-Programmiung + Threads. Geht auch grundsätzlich schief, ... manchmal nich, manchmal schon, manchmal _arg_ komisch.

IDLE ist nicht unbedingt schlecht, aber ... ich finds nich besonders schön, um ehrlich zu sein. GUI-Programmierung ist damit eher mässig, Logikprogrammierung is auch manchmal so'ne Sache, wenn man beispielsweise Threads verwendet oder mehrere Programme übers Netzwerk kommunizieren lässt. Das alles sind Fehler, die du in den Bugreports auf der Seite nachlesen kannst und das sind auch alles keine gravierenden Fehler für einen Anfänger. Aber sie lassen sich, durch die Beschaffenheit von Tkinter und der Programmierung von IDLE über einen localhost Socket, nicht so einfach beheben. IDLE is für'n Anfang ganz knuffig und für's schnelle bearbeiten von Dateien und so... Aber es gibt bessere IDE oder Editoren, finde ich zumindest.

Und die Buggykeit von IDLE lässt sich definitiv nicht bestreiten, weil's, wie gesagt, einfach in der Beschaffenheit des Programmes liegt.

[Leonidas]

Startet man IDLE ohne Subprozess (und das ist hier offenbar der Fall gewesen), merkt sich IDLE alle Importe etc., so lange man es nicht komplett schließt und neu startet. Startet man IDLE mit Subprozess, ist das nicht so. Das ist kein Bug, sondern definiertes Verhalten von IDLE. Wird - so weit ich mich erinnere - in der IDLE-Doku auch drauf hingewiesen.

Also für mich klingt der Start ohne Subprozess wie ein Bug. vi hat auch Bugs, obwohl diese "dokumentiertes Verhalten" sind (und von vi-Klonen emuliert werden können).

[HerrHagen]

Ich muss den Kritikern teilweise Recht geben. Das ausführen von Programmen in IDLE ist so eine Sache... mal gehts - mal gehts nicht. Die Probleme lassen sich meißt alle irgendwie fixxen (z.B. plotten mit matplotlib). Aber was ist das für eine IDE, die für jedes Problem extra angepasst werden muss? Ich kann euch auch gern Code geben der in ner normalen Shell funktioniert und unter IDLE nicht. (hat noch nicht mal was mit Tkinter zu tun).
Der Grund warum ich IDLE trotzdem mag und einsetze ist die Code-Completion. Die funktioniert - im Gegensatz zu den meißten Editoren. Starten kann man das Programm dann immer noch von außerhalb. (damit ein Modul für die Completion verfügbar wird, reicht es auch diese in der "IDLE-Shell" zu importieren - man muss es nicht über IDLE starten). Und gerade zum Ausprobieren von kleinen Ideen oder zum Spielen mit numpy und matplotlib ist es ganz hervoragend geeignet.
Eigentlich müsste man mal IDLE überarbeiten. Schließlich wird es mit der Stadard-Distribution mitgeliefert und ich finde es ein wenig blamabel, dass es so viele Schnitzer hat.

MFG HerrHagen