[Python-de] ich suche die Datei "pythonrun.c"

Georg Mischler schorsch at schorsch.com
Sun May 12 22:50:23 EDT 2002


Gerhard Häring wrote:

> C:\tmp\build\lib.win32-2.2>c:\tmp\py\python_d.exe
> Adding parser accelerators ...
> Done.
> Python 2.2.1 (#34, May 13 2002, 02:16:05) [MSC 32 bit (Intel)] on win3
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import crash
> [7974 refs]
>
> Visual C++ anwerfen; Build/Start Debug/Attach to Process; python_d.exe
> auswählen; File crash.c öffnen und Breakpoint auf "*ptr = 'X';" setzen. Danach
> in der interaktiven Python-Session crash.crash() ausführen. Voilà: der
> Breakpoint wird erreicht.


Das haette man natuerlich gerne etwas eleganter... ;)

Wenn du dein Programm mit Python erweiterst, also ein
#include "Python.h" drinstehen hast, dann wird bei einem Debug-Build
automatisch die Python##_d.dll eingebunden. Danach kannst du ganz
normal dein Programm direkt debuggen, und von dort aus auch auf alle
Python-Interna sowie auf eventuelle Erweiterungsmodule zugreifen.
Voraussetzung ist natuerlich, dass alle diese Komponenten
ebenfalls als Debug-Version vorliegen, und dass VC alle notwendigen
DLLs findet.

Wenn du "nur" eine Erweiterung entwickelst, ist es aehnlich einfach.
Du gibst dann als auszufuehrendes Programm beim Debuggen schlicht
den Debug-Build des Interpreters an (python_d.exe), und wieder hast
du mit F5 eine normale Debug-Session am laufen. Wenn du im Code deiner
Erweiterung einen Breakpoint gesetzt hast, dann kannst du in der nun
erscheinenden Konsole "import modulname" eingeben, und sobald
der Breakpoint erreicht ist, fuehlst du dich gleich wieder zuhause.

Ob Python selber mit oder ohne Distutils kompiliert wurde, sollte
dabei eigentlich erst mal keine Rolle spielen. Schliesslich solltest
du am C-Code des Interpreters auch nichts aendern, sondern bestenfalls
Schrittweise durchmaschieren, um zu schauen, was da eigentlich
passiert. Zu Verrenkungen wie dem externen Anflanschen des Debuggers
an ein schon laufendes Programm wird es dabei nur sehr selten einen
guten Grund geben.


-schorsch

-- 
Georg Mischler  --  simulations developer  --  schorsch at schorsch.com
+schorsch.com+  --  lighting design tools  --  http://www.schorsch.com/




More information about the Python-de mailing list