51–60 of 100 posts
Most notably, pydbgr has out of process debugging, so you can attach to a server process and diagnose a deadlock, for example.
Debuggers are cool and often necessary, but I disagree with this often-expressed sentiment that print-debugging is a primitive hack for people who don't know any better. Debugging is determining the point at which the program's expected behavior diverges from its actual behavior. You often don't know where where/when this is happening. Print-debugging can give you a transcript of the program's execution, which you ca…
Yes.
>Stepping through a program's execution line-by-line and checking your assumptions can be a lot slower in some cases.
Yes again, particularly when the code is in a loop. Whereas, if you use print-debugging, even though the output will be repeated as many times as the loop runs, you at least have the possibility of grepping to filter it down to relevant (e.g. erroneous/unexpected) output.
Here's a simple Python debugging function that may be useful:
http://jugad2.blogspot.in/2013/10/a-simple-python-debugging-...
Debuggers are cool and often necessary, but I disagree with this often-expressed sentiment that print-debugging is a primitive hack for people who don't know any better. Debugging is determining the point at which the program's expected behavior diverges from its actual behavior. You often don't know where where/when this is happening. Print-debugging can give you a transcript of the program's execution, which you ca…
Earlier quoted context omitted.
To expand on your point, I look at print statements in the same light as goto statements. There is a time and place for both, just make sure it's the best tool to accomplish your goal. In C I often use gotos for error handling, but I wouldn't use them in situations where higher-level branching constructs are more suitable. Similarly, sometimes you don't need the features of a heavy-weight debugger but just want to ch…
Normally I wouldn't comment on someone downvoting me. However I'm going to presume there is a very high probability that it's due to my analogy with the goto statement, something which most programmers seem to view as inherently evil thanks either to received dogma or to a misunderstanding of the context of Dijkstra's original paper on the subject. The point of my post was that there is a time and place for everythin…
The most frustrating thing (experienced in both Javascript and Python) is the "oh uncaught exception? let me just quit everything" model. Most of the time, if I were just given an interactive prompt right then, I could spend 1 minute looking at local variables, maybe get a special stack trace variable to look at that, then be over with it. Instead I have to stick in some print statements and start everything over aga…
Earlier quoted context omitted.
How would I do that with something like django?
You are right that this is not straight forward in Django. There are a number of different routes in Django development that you may need to debug: 1. Debugging view endpoints when not using runserver (for example when testing out your actual deploy webserver). For this, none the debuggers will work, as you have no console to run through. I combat this by using winpdb that allows remote debugging. 2. Debugging either…
$ python -m pdb manage.py test
(Pdb) break mymodule/myfile.py:42
(Pdb) c
I wonder if you could also use it with runfcgi or any of the other manage commands? I personally use nginx+gunicorn, but for testing production I could switch it to runfcgi or similar really quick.
To be honest though, I don't find myself ever debugging production.
Earlier quoted context omitted.
We avoid that by having a build step fail if 'import pdb' exists in our codebase. You could do similar for any of these tools. This will then lead to build failures in one's automated build system, and flag pull requests as not-yet-ready to be merged with our master branch. If one doesn't have an automated test process, then I suspect one has bigger potential errors that could sneak in than an errant pdb breakpoint.…
Sure, that's beautiful in theory. But you have to remember to catch the strings "import pdb", "import ipdb", "import pydbgr", and the variations "from pdb import Pdb", "__import__('pdb')", all the permutations, and so on. Anyway, that's besides point. Having to change the source to fire the debugger is a dumb way of debugging after all, and doesn't allow certain things (e.g., step thru a 3rd party library). Better co…
I guess it's because that is an example of ad-hoc (which typically misses a lot of edge conditions) tooling created to make up for language (or in this case tooling) inadequacies.
Debuggers are cool and often necessary, but I disagree with this often-expressed sentiment that print-debugging is a primitive hack for people who don't know any better. Debugging is determining the point at which the program's expected behavior diverges from its actual behavior. You often don't know where where/when this is happening. Print-debugging can give you a transcript of the program's execution, which you ca…