Das deutsche Python-Forum

Moin moin,
bin Python-Neuling und ebenfalls neu hier im Forum.

Vorweg: Ich experimentiere gerade aus reinem Interesse an der Materie mit Python herum, deshalb wundert euch bitte nicht über dumme Fragen, auch wenn es solche ja angeblich nicht geben soll.

Hergeführt hat mich eine Frage die ich mit Hilfe von Google nicht beantworten konnte bzw. zu keiner funktionierenden Lösung gekommen bin.

Das Problem betrifft die Shebang-Zeile am Anfang meiner/einer Python-WebApp.
Im Sinne der Portabilität muss es doch möglich sein einen allgemein gültigen Python-Pfad zu deklarieren, sodass ein Python-Skript ohne Anpassungen an der Shebang vorzunehmen z.B. direkt im Browser aufgerufen werden kann und zwar von jedem Webserver aus.

Wie kann ich am Beispiel von XAMPP (welches ich lokal nutze) den Python-Pfad für den Webserver hinterlegen, sodass meine *.py's ohne Shebang auskommen? :K

@no.cigar: Wir müssten erst einmal klären wie Du Deine Webanwendung in den Webserver einbindest. CGI, WSGI, mod_python? (Letzteres hoffentlich nicht mehr — das ist tot.)

Bei WSGI stellt sich das Problem nicht. Und bei CGI ist es nicht möglich weil das nichts mit dem Webserver zu tun hat, der startet nur ein externes Programm wobei ihm völlig egal ist was das für eine ist und wie das ausgeführt wird. Da hat sich das Betriebssystem drum zu kümmern.

Hallo BlackJack!

Ja bei mod_python bin ich auch schon gelandet, habe mich aber gerade aus dem genannten Grund davon abschrecken lassen.

Ok, ich hätte eventuell gleich deutlicher sein müssen:
Im moment betrachte ich Python als Abwechslung zu PHP und bin daher noch gar nicht so tief eingestiegen.
Dass es mit CGI de facto nicht möglich ist, ist auf jeden Fall schon einmal gut zu wissen. Aber wie sieht es denn mit den py-Skripten aus die ich direkt über meinen Browser aufrufe? Brauchen diese in jedem Fall eine Shebang?

Also z.B.
...möchte ich unter http://localhost/hallo.py aufrufen unabhängig von der Webserverumgebung, da ich lokal Windows nutze und auf dem Webserver UNIX.
Faul wie ich bin suche ich natürlich nach einer Möglichkeit die Shebang im Anschluss nicht immer abändern zu müssen.

Das was du beschreibst ist CGI.

Oh, klasse!

Also nicht möglich...schade.

Na ja, Fachlektüre ist bereits unterwegs.

Und bei CGI stellt sich das Problem bei Windows vs. Linux nicht weil Windows anhand von Dateiendungen entscheidet wie eine Datei ausgeführt wird und Linux die Shebang-Zeile verwendet. Da muss man also nichts ändern.

Letztendlich will man aber gar kein CGI verwenden sondern WSGI.

no.cigar hat geschrieben:

Code: Alles auswählen

#!C:/python33/python.exe
print "Hallo Welt"

Jetzt mal unabhängig davon, dass es für das konkrete Problem wohl nicht nötig ist: Windows kennt keine Shebangs. Das läuft - wie schon geschrieben wurde - nur über die Windows-eigene Erkennung der Dateiendung. Will man trotzdem eine explizite Angabe der Python-Version im Quelltext haben, die auch unter Windows verstanden wird, dann ist es zumindest möglich, den ab Python 3.3 eingebauten Mechanismus zur Interpretation eines Shebangs zu nutzen (weitere Infos hier). Ob man das brauchbar findet, sei jedem selbst überlassen. Wie gesagt: Eine automatische Ausführung der passenden Interpreter-Version (z.B. hinsichtlich 2.x vs. 3.x Code) ist damit nur sehr bedingt möglich, weil man vor 3.3 eher keinen vorinstallierten "Shebang-Interpreter" erwarten sollte und die Shebang-Angabe unter Windows daher ins Leere läuft.

Sobald ich allerdings die Shebang in dem oben aufgeführten Kurzprogramm weglasse, spuckt mir XAMPP bzw. Apache 2.4.3 unter Windows folgenden Fehler aus:

Serverfehler!

Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Der Server ist entweder überlastet oder ein Fehler in einem CGI-Skript ist aufgetreten.

Sofern Sie dies für eine Fehlfunktion des Servers halten, informieren Sie bitte den Webmaster hierüber.

Error 500

@no.cigar: Und was steht dazu in den Logs?

Könnte sein das Apache die Shebang benutzt um bei CGI den Interpreter bei Skripten zu ermitteln.

Hier liegt der Fehler, werde mich mal umschauen.