I am just wondering if there is a way to add breakpoints in IDLE so that I can stop at a point in my script and write other lines in the idle shell for testing. If not, is there other software that can do this?
you can add the line
import pdb; pdb.set_trace()
anywhere in your code, when reached it will drop you into a debug shell. so useful i have an emacs shortcut to add the snippet.
you may also want to look at ipdb, and use
import ipdb; ipdb.set_trace()
instead
http://docs.python.org/library/pdb.html
If you are running Windows, you might look at PyScripter if you want a development environment with more features than IDLE.
Related
I am a Perl programmer learning Python. I am writing my code in emacs debugging with python -m pdb script.py using Python 2.7.3.
I would like to know what is the python equivalent to in Perl adding a $DB::single=1;1; to a specific line of python code, so that when running the debugger, it will stop there, even if it's a different source code file from where the execution started (e.g. a line of code in a library being used by script.py).
Any ideas?
EDITED: after looking at pdb.set_trace() or ipdb.set_trace(), I consider them good solutions but not 100% identical to the behaviour of $DB::single=1;1;. This is, I would like the breakpoint to be on the set_trace line, instead of the next line. This is accomplished in Perl's $DB::single=1; by adding another statement in the same line: 1;, which makes it $DB::single=1;1;.
Using set_trace(), I get the breakpoint at the line after the statement, even if I add 1; after it. Still not fully understanding how Python treats multi-statement lines in comparison to Perl.
Anybody?
Any ideas?
Is the following satisfying your needs ?
import ipdb; ipdb.set_trace()
just write it somewhere in your code and run your script with python script.py.
you need the ipython debugger (ipython is an enhanced python interpreter):
pip install ipdb
edit: did you know that if you run M-x pdb RET pdb myscript.py RET, you'll have a pdb prompt and emacs will track the source code in another buffer, but it doesn't stop where you defined ipdb.set_trace() ?
Virtual Env ?
if you use virtual envs, you have a couple of options. I recommand installing virtualenvwrapper from ELPA and run M-x venv-workon.
Python comes with debugger called pdb. To stop a script at given point in code put the following
import pdb; pdb.set_trace()
Since you are using emacs, you would may want to try out the command pdb provided by gud.el (correction: You do not need to preload 'python-mode' to run pdb, thanks #Andreas Röhler for correction) . Start it by pdb name_of_script.py, then you can set breakpoint from emacs by pressing C-xSPACE at the line you want to set breakpoint at. I recommend you to use menu-bar to explore the commands provided by the debugger (GUD). You can also use the usual pdb commands in the *gud-pdb* buffer started by emacs.
There is a high level logic error deep within my Python script, and pdb doesn't help to debug it. Is there any other way to see what is being executed after I run my script?
NOTE: Using pdb is too slow and inconvenient - I wish I could grep over all cases when my function is executed, instead of inspecting manually each and every call, set/unset breakpoints. The state is lost when I exit pdb and its user interface is more confusing than helpful - requires docs at hand.
UPDATE: made it clear that pdb is not an option, so the most popular Python debugging tips can not be applied
I would recommend using pdb. You can use
import pdb
at the top of your script, and then add the line
pdb.set_trace()
somewhere in the code where you want to trace the problem. When the script gets to that line, you will have an interactive console where you can check variable values, run your own checks, and see what is going on. You can use n to execute the next line, or c to continue to the next occurrence of set_trace(). Full documentation is here: http://docs.python.org/2/library/pdb.html.
Let me know if you have any specific questions!
No, there's no magic formula.
My best suggestion is to get a good IDE with a debugger, like JetBrains' PyCharm, and step through your code to see where you went wrong.
Most of the time these situations happen because you make assumptions about behavior that aren't true. Get a debugger, step through, and check your assumptions.
I found a way to do this using excellent trace module that comes with Python.
An example how to troubleshoot module installation problem:
python -m trace -t setup.py install > execution.log
This will dump all source line of setup.py install execution to execution.log. I find this more useful than pdb, because usability of pdb command line interface is very poor.
I'm wondering if anybody has a hint on how to debug a unittest, or any other piece of code in django, for that matter, using a debugger like winpdb?
I'm trying to to a
winpdb manage.py test photo
which runs my unittest for my photo app, but winpdb crashes. Are there alternatives? What is the best way to do this?
I'm running linux, ubuntu 10.10.
You can use pdb to debug your program.
import pdb
def some_function():
pdb.set_trace()
some_other_computation()
When the program hits the set_trace method, execution will pause, and you will be put into an interactive shell. You can then examine variables, and step through your code.
Look at pudb, it is a full-screen, console-based visual debugger for Python. Very nice for debugging with good console UI.
import pudb
def some_function():
pudb.set_trace()
some_other_computation()
You'll need to pass the -s option (eg: python manage.py test -s), to turn off output capturing (which prevents the debugger from starting).
Add following lines to your code:
import rpdb2;
rpdb2.start_embedded_debugger_interactive_password()
You can find more information here: http://winpdb.org/docs/embedded-debugging/
The problem is that django creates another process in which it runs the application under test. So you can not just use winpdb on your main django process.
You should put a call to rpdb2 debugger (winpdb internal debugger) just before the place you want test and attach with winpdb to that running debugger.
See a tutorial here: https://code.djangoproject.com/wiki/DebuggingDjangoWithWinpdb
I'm developing a django app using aquamacs as my ide. Pdb isn't working since upgrading to emacs 23.2.1 using python 2.6.1. When I invoke pdb like this:
M-x pdb
Run pdb (like this): pdb ./manage.py runserver
The gud-manage.py frame appears with this message (and nothing more) -
Current directory is /path/to/my/source/
It isn't responsive to keyboard input, though I can right-click and send a quit or kill signal. It seems like emacs isn't capturing the pdb output correctly.
Has anyone seen this and (hopefully) fixed it? I believe it has something to do with the gud-pdb-marker-regexp variable (see point #2 in link).
Related issues
Seems to have been around since 2007
One person a solution for this problem on Windows (adding -u to the python command in the pdb script). I tried it anyway, but this didn't work for me.
Same issue (Current directory is ...) to me with emacs 23.2 (9). As you mentioned, it is caused by a CR/LF ending and can be fixed by setting the gud-pdb-marker-regexp.
I added the CR (\r) to the gud-pdb-marker-regexp. May you want to add the following line to your .emacs file and give it a try.
(setq gud-pdb-marker-regexp "^> \\([-axx-zA-Z0-9_/.:\\]*\\|<string>\\)(\\([0-9]+\\))\\([a-zA-Z0-9_]*\\|\\?\\|<module>\\)()\\(->[^\n\r]*\\)?[\n\r]")
Not sure if that is the case for you, but just to mention it: PDB hangs for me in Emacs when the source code path contains a space - when I move the python file to a directory without a space in the name, it works (on Emacs 23.1.1).
I have been having this same issue. I had it fixed in 23.1 (http://debbugs.gnu.org/db/56/5653.html) but now in 23.2 that fix no longer works, or at least it doesn't appear to for me. I've just submitted a bug to Emacs explaining the problem in detail and hopefully it will get resolved.
A workaround for this is to execute pdb from the emacs shell:
Open the shell: M-x shell
Enter this in the shell: pdb
This will get pdb working properly within the shell.
When programming in the two IDEs i used, bad things happen when i use raw_input. However on the command line it works EXACTLY how i expect it to. Typically this app is ran in cmd line but i like to edit and debug it in an IDE. Is there a way to detect if i executed the app in an IDE or not?
if sys.stdin.isatty():
# command line (not a pipe, no stdin redirection)
else:
# something else, could be IDE
I would strongly advise (and you have been previously advised on this) to use a good IDE, and a good debugger instead of hacking around your code to fix something that shouldn't be broken in the first place.
I deserve to be down-voted for not answering the question, but please consider this advice for your future sanity.
I would personally recommend Winpdb debugger and PIDA IDE