Debugging in WebApp mit __debug__ ?

[jens]

Kann man __debug__ in einer WebApp nutzten und dann das machen:

Code: Alles auswählen

#!/usr/bin/python -o

Weiß noch nicht so ganz, was man damit effektiv anfangen kann, aber vielleicht ist es hilfreich in PyLucid...

Nutzt das jemand?

[Leonidas]

Nutzt das jemand?

Nein, ich nutze zum Debuggen von Webapps immer Djangos-Debug machanismen. Ich habe eine settings.py, die die Prodktiv-Einstellungen enthält und daneben eine develsettings.py, die settings.py importiert und die Debug-Sachen einschltet. Die settzings.py wird dann vom FastCGI-Server verwendet, die develsettings.py vom Development-Server. Ich muss zugeben, dass das ziemlich komfortabel ist.

[birkenfeld]

1. "nutzen"
2. "python -O"

[jens]

1. "nutzen"
2. "python -O"

Nicht so viel Info's auf einmal

Also erstmal, geht überhaupt in einer WSGI Handler Datei:

Code: Alles auswählen

#!/usr/bin/python -o

Ich denke mal schon, oder?

Ansonsten hab ich mir überlegt, ich kann das schon ganz gut in PyLucid gebrauchen. Dann kann ich oft if __debug__: self.page_msg("Tolle Debug Ausgaben") machen...

Irgendwo habe ich gelesen, das angeblich die __debug__ Abschnitte komplett ignoriert werden (also in der *.pyc nicht gespeichert werden), wenn man den Interpreter mit -o startet, was ja für optimize steht... Stimmt das?

[birkenfeld]

1. "nutzen"
2. "python -O"

Nicht so viel Info's auf einmal

Scheinbar hats nix gebracht.

Also erstmal, geht überhaupt in einer WSGI Handler Datei:

Code: Alles auswählen

#!/usr/bin/python -o

Ich denke mal schon, oder?

Nein, weil es -O ist.

Ansonsten hab ich mir überlegt, ich kann das schon ganz gut in PyLucid gebrauchen. Dann kann ich oft if __debug__: self.page_msg("Tolle Debug Ausgaben") machen...

Irgendwo habe ich gelesen, das angeblich die __debug__ Abschnitte komplett ignoriert werden (also in der *.pyc nicht gespeichert werden), wenn man den Interpreter mit -o startet, was ja für optimize steht... Stimmt das?

if __debug__ wird bei -O rausoptimiert, ja. Mit der .pyc hat das aber nix zu tun weil optimierter Bytecode in .pyo geschrieben wird.

[jens]

if __debug__ wird bei -O rausoptimiert, ja. Mit der .pyc hat das aber nix zu tun weil optimierter Bytecode in .pyo geschrieben wird.

Aha! Siehst du, das wußte ich noch nicht... Gut das ich nochmal nachgefragt hab
Ich werde mir das demnächst mal anschauen, doch ein Problem sehe ich jetzt schon. Mir fehlt irgendwie ein Debug-Level. Denn welche Debug-Ausgaben sollte ich machen? Jede Kleinigkeit oder "nur die wichtigsten" oder ein Mittelding

Aber vielleicht mache ich mir dann selber in PyLucid ein Debug-Level

[Joghurt]

http://docs.python.org/lib/module-logging.html

[jens]

if __debug__ wird bei -O rausoptimiert, ja. Mit der .pyc hat das aber nix zu tun weil optimierter Bytecode in .pyo geschrieben wird.

Noch eine dumme Frage... Was wird noch "optimiert" oder war es das schon?

Wo finde ich Informationen in der Doku dazu?

[Joghurt]

Noch eine dumme Frage... Was wird noch "optimiert" oder war es das schon?

Asserts werden rausgeschmissen.
Bei -OO werden auch die Docstrings entfernt.

Und das war's auch schon.

Deshalb niemals "assert" als allgemeine Fehlerbehandlung nehmen. SQLObject war da glaube ich ein schlechtes Beispiel.

[CM]

o.T. Auch wenn ich mir hier als totaler Ignorant oute: Benutzt jemand von euch assert? Ich habe zwar diverse Fehlerbehandlungsroutinen drin, aber der Sinn von assert ist Python doch nicht so groß wie in C++, oder? Also kommt bei mir assert sehr selten vor (habe gerade nachgeschaut: sehr selten, aber es kommt vor).

Christian

[Y0Gi]

Ich benutze es sehr selten, weil es dem Sinn von dynamic/duck typing auch irgendwie zuwider läuft. Indem man einfach Funktionen mit dem füttert, was sie erwarten, spart man sich intensives Type-Checking. Und dann gibt es ja noch Exceptions und gute Möglichkeiten, auch in Webanwendungen damit umzugehen (z.B. cgitb sowie die zugehörige als auch die EvalException-Middleware in Paste).

[Leonidas]

Auch wenn ich mir hier als totaler Ignorant oute: Benutzt jemand von euch assert?

Nein, so ein großer Ignorant bist du nicht, oder wir sind beide gleich große Ingnoranten, aber auch ich nutze assert so gut wie nie.. moment, ich denke ich nutze es überhaupt nicht. Ich hatte nichtmal die Notwendigkeit es einzusetzen. Dafür funktionieren Exceptions zu gut.

Und dann gibt es ja noch Exceptions und gute Möglichkeiten, auch in Webanwendungen damit umzugehen (z.B. cgitb sowie die zugehörige als auch die EvalException-Middleware in Paste).

Der Traceback von Django ist auch ziemlich praktisch, also bin ich auch da positiv überrascht gewesen.

[jens]

Asserts werden rausgeschmissen.
Bei -OO werden auch die Docstrings entfernt.

Asserts nutzte ich überhaupt nicht... Das die Docstrings raus kann ja auch nicht schaden, wobei es das auch nicht viel schneller macht, was? Und die Speichereinsparung dürfte auch nicht die Welt sein.

Dann nehme ich statt -O lieber direkt -OO...

[Y0Gi]

Für das reine Deployment einer Anwendung sind die Docstrings wohl egal, ja. Aber in anderen Fällen können sie durchaus hilfreich sein, etwa wenn sich ein Code-fremder Entwickler an das Paket macht und help() nutzen möchte.

[jens]

Ja, moment... So wie ich das verstehe, werden die DocStrings doch wohl nur in den *.pyo Dateien nicht übernommen. Aber sie werden doch wohl nicht in den *.py gelöscht...

Wenn man Entwickelt, z.B. mit colubrid's http-Server dann sind die DocStrings hilfreich. In einem Traceback kann man z.B. interactiv help(bla) eingeben... Aber dann verwendet man sowieso nicht die -OO Variante

Bei PyLucid wird nur -OO bei den CGI-Handlern eingefügt und da auch nur bei den ohne Debug.
Zur Info: Ich liefer bei PyLucid vier CGI-Handler mit:

• CGI_Handler.py
  CGI_Handler_Debug.py
  CGI_Handler_with_Backports.py
  CGI_Handler_with_Backports_Debug.py

Die ersten beiden sind für Python 2.4 gedacht, die anderen für Python 2.3