So, I started learning to code in Python and later Django. The first times it was hard looking at tracebacks and actually figure out what I did wrong and where the syntax error was. Some time has passed now and some way along the way, I guess I got a routine in debugging my Django code. As this was done early in my coding experience, I sat down and wondered if how I was doing this was ineffective and could be done faster. I usually manage to find and correct the bugs in my code, but I wonder if I should be doing it faster?

我通常只使用Django启用时提供的调试信息。当事情确实像我想象的那样结束时,我用一个语法错误破坏了代码流,并查看流中那个点的变量,以找出代码在哪里做了与我想要的不同的事情。

但这种情况还能改善吗?是否有一些更好的工具或方法来调试Django代码?


当前回答

对于那些不小心将pdb添加到实时提交的人,我可以建议这个扩展#Koobz的答案:

@register.filter 
def pdb(element):
    from django.conf import settings
    if settings.DEBUG:    
        import pdb
        pdb.set_trace()
    return element

其他回答

调试Django代码的最佳选择之一是通过wdb: https://github.com/Kozea/wdb

wdb works with python 2 (2.6, 2.7), python 3 (3.2, 3.3, 3.4, 3.5) and pypy. Even better, it is possible to debug a python 2 program with a wdb server running on python 3 and vice-versa or debug a program running on a computer with a debugging server running on another computer inside a web page on a third computer! Even betterer, it is now possible to pause a currently running python process/thread using code injection from the web interface. (This requires gdb and ptrace enabled) In other words it's a very enhanced version of pdb directly in your browser with nice features.

安装并运行服务器,并在代码中添加:

import wdb
wdb.set_trace()

作者认为,pdb的主要区别是:

For those who don’t know the project, wdb is a python debugger like pdb, but with a slick web front-end and a lot of additional features, such as: Source syntax highlighting Visual breakpoints Interactive code completion using jedi Persistent breakpoints Deep objects inspection using mouse Multithreading / Multiprocessing support Remote debugging Watch expressions In debugger code edition Popular web servers integration to break on error In exception breaking during trace (not post-mortem) in contrary to the werkzeug debugger for instance Breaking in currently running programs through code injection (on supported systems)

它有一个很棒的基于浏览器的用户界面。一种使用的乐趣!:)

我刚找到wdb (http://www.rkblog.rk.edu.pl/w/p/debugging-python-code-browser-wdb-debugger/?goback=%2Egde_25827_member_255996401)。它有一个非常漂亮的用户界面/ GUI,所有的铃铛和口哨。作者这样说wdb -

“像PyCharm这样的ide有自己的调试器。它们提供了相似或相同的功能……然而,要使用它们,你必须使用那些特定的ide(其中一些是非免费的,或者可能不适用于所有平台)。根据你的需要选择合适的工具。”

我想我应该把它传下去。

这也是一篇关于python调试器的非常有用的文章: https://zapier.com/engineering/debugging-python-boss/

最后,如果你想在Django中看到一个漂亮的调用堆栈的图形打印输出,checkout: https://github.com/joerick/pyinstrument。只需将pyinstrument.middleware.ProfilerMiddleware添加到MIDDLEWARE_CLASSES中,然后将?profile添加到请求URL的末尾以激活剖析器。

也可以从命令行或导入作为模块运行pyinstrument。

到目前为止,几乎所有的东西都已经提到了,所以我只补充一点,可以使用ipdb.set_trace()而不是pdb.set_trace(),它使用iPython,因此更强大(自动完成和其他好东西)。这需要ipdb包,所以你只需要pip安装ipdb

一个关于模板标签的小窍门:

@register.filter 
def pdb(element):
    import pdb; pdb.set_trace()
    return element

现在,在模板中,您可以执行{{template_var|pdb}}并进入pdb会话(假设您正在运行本地devel服务器),在那里您可以检查元素到您的心的内容。

这是一种很好的方式,可以看到当对象到达模板时发生了什么。

我使用PyCharm并一直支持它。我花了一点钱,但我不得不说我从中得到的好处是无价的。我尝试过从控制台调试,我确实很信任那些能做到这一点的人,但对我来说,能够直观地调试我的应用程序是很棒的。

我不得不说,PyCharm确实占用了很多内存。但话说回来,生活中没有什么好东西是免费的。他们刚刚发布了最新版本3。它也可以很好地与Django, Flask和谷歌AppEngine一起使用。所以,总而言之,我认为这是任何开发人员都可以拥有的一个非常方便的工具。

如果你还没有使用它,我建议你试用30天,看看PyCharm的强大功能。我相信还有其他可用的工具,比如Aptana。但我想我也喜欢PyCharm的外观。我觉得在那里调试我的应用程序很舒服。