11

Think about this scenario:

I debug my Django project and I step through the code (in and out). The debugger sometimes enters Django libraries or other external libraries.

Does anyone know how to prevent the debugger from entering external code? Or at least a 'big' step out to get the debugger back to the project code?

Wouter J
  • 41,455
  • 15
  • 107
  • 112
Dan
  • 111
  • 1
  • 5

2 Answers2

9

Does anyone know how to prevent the debugger from entering external code?

Yes, Dmitry Trofimov knows;

(...) add modules you don't want to trace to the dict DONT_TRACE in <pycharm-distr>/helpers/pydev/pydevd.py
That is a hacky solution (...)

If you want this feature to be less hacky you can vote on it by visiting issue
PY-9101 Implement "Do not step into the classes" option for Python debugger

Those using pdb might be interested to know there is such a feature in pdb;

Starting with Python 3.1, Pdb class has a new argument called skip -

class pdb.Pdb(completekey='tab', stdin=None, stdout=None, skip=None, nosigint=False)

The skip argument, if given, must be an iterable of glob-style module name patterns. The debugger will not step into frames that originate in a module that matches one of these patterns. 1

1 Whether a frame is considered to originate in a certain module is determined by the __name__ in the frame globals.

The example given in the docs shows how to skip Django's packages -

import pdb; pdb.Pdb(skip=['django.*']).set_trace()

Piotr Dobrogost
  • 41,292
  • 40
  • 236
  • 366
1

Everything looks the same to the debugger, it can't distinguish between your code or Django's code – it's all Python. So it will run everything, however if you want to stop it from drilling down so low you'll have to start “stepping over” lines of code instead of “stepping into” them.

According to the PyCharm docs you'll want to use F8 when ever you see a line of code that looks like it could be a gateway into Django's internals. If you accidently find yourself inside Django's source code you can hit Shift+F8 until you're out of it.

Matt
  • 8,758
  • 4
  • 35
  • 64
  • 2
    Thanks guys for the answers! Indeed Shift+F8 is what I have used so far, I just found it tedious and a waste of time. Although occasionally I would look at Django's code, most of time I look at my project. Maybe it will be a feature in future versions of PyCharm. – Dan Mar 01 '13 at 20:23
  • It won't be a feature in future versions, because it's not needed. Breakpoints and stepping over lines of code already solve this. – Matt Mar 01 '13 at 20:37
  • 2
    *it can't distinguish between your code or Django's code* By setting a breakpoint you tell debugger where to stop. Why do you think there can't be a way to tell debugger where not to stop? See the question [How can I configure Qt Creator and/or gdb so that while debugging my program using Qt libraries the debugger would avoid stepping into Qt's source files?](http://stackoverflow.com/q/1448426/95735) which shows there is such a mechanism in `gdb`. If one debugger has this feature other debuggers can have it probably too. – Piotr Dobrogost Mar 03 '13 at 12:46
  • 1
    It's also a feature (as "blackboxing") in Google developer tools. Basically, the point is that encapsulation and information hiding should be things you can direct your debugger to honor with a quick decision to "blackbox this namespace." The Django developers have already done the work of debugging their framework - for the most part, I shouldn't have to concern myself with the internals (there are a few situations when I would, sure, and have - but those are 1/100 as common as the times I just want to treat a library function as an oracle). – outis nihil Nov 21 '14 at 16:10