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. 11 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()
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.
- Django backup strategy with dumpdata and migrations
- Django translations and gettext: The deprecation of the % (string interpolation) operator