pdb.py - 为什么这个调试器与所有其他调试器不同？ [英] pdb.py - why is this debugger different from all other debuggers?

问题描述

好吧，有点夸张。


最近，我更认真地使用Python，并且在使用

调试器时我认为我注意到的第一件事就是

没有重启 （per中的R）或run中的R。 （gdb）命令。


我很高兴发现它是多么容易，虽然它是补丁pdb.py

和pdb.doc;我的补丁就在这里：
http://sourceforge.net/tracker/index...70&atid=305470


鼓励，我注意到的下一件事缺乏从我平时的调试

repertoire是gdb'的'frame"命令是绝对位置

版本的up和向下。显然，因为向上和向下在那里，

添加一个框架命令也很简单。


也许我应该解释一下，我注意到缺少并想要一个

" frame"命令，因为我注意到在添加重启

之前，当程序通过事后转储重新启动时，后面的

第一行号 - mortem dump没有被报道。所以

Emacs在源头显示了一个奇怪的位置;令人困惑的是，并且b $ b不清楚是否实际发生了重启。当Emacs和

调试器不同步时，我通常的解决方法是发出

frame 0，这通常意味着转到顶部（或它是底部？）
堆栈的副作用是强制emacs更新显示器。


嗯，现在我们到达第二个问题。 Python的堆栈编号是

与大多数（所有？）其他语言的方式不同。并且向上并且

向下在pdb.py中遵循Python的方向概念而不是

调试器中常见的东西。是的，我意识到Python的堆栈

编号是正确的方法;我毫不怀疑Python

程序员用底部的根绘制树。所以至少

现在我入侵了frame -1通常称为框架

0的意思是什么在其他调试器中。并且帧0和帧0在我的私人黑客pdb.py去了最近最近遇到的条目或者祖父地点的


调用所有其他人。


最后，我们来列出断点。显示我的gdb方向，

尝试和寻找的第一件事是信息中断。不，不是那里的b $ b。有一段时间我只是觉得一个人不能列出断点

并与之共存。然后，当我决定我会破解信息中断

时，我意识到如果你输入break，那么没有任何参数，它列出了

断点。 （是的，我看到行为已记录在案。）


实际上，断点列表输出看起来类似于gdb

使用的内容。这很好，但是在gdb和Perl的调试器中，break

没有参数*设置*当前行的断点，它

并没有列出它。


在这里，我对于该做什么感到有些困惑。我的意思是

只是改变break的行为，所以它就像其他调试器一样工作

。与框架相反。命令，我看不出怎样

pdb.py'的术语列出断点"优越。事实上它似乎比较差。如果想要扩展调试器命令集以包括

a列出关于断点号n的信息 （gdb通过

" info break n"），我不确定这是否符合现有的

术语。


我的猜测是pdb.py起初是一项小任务，并且在没有充分考虑或担心什么是完整的调试器

命令的情况下增长了b $ b设置应该或将是。


所以我建议的是，只需遵循一个

现有的调试器范例（或者更密切地关注）所以大家不要这么多b $ b必须学习另一个界面。


当我尝试一些东西时，让我以愉快的体验结束

在我的Bash调试器中（ http://bashdb.sourceforge.net）。在

这样做我决定我只是尝试遵循gdb命令集。不是我认为gdb'是最精彩，正交或精心设计的

命令集，但只是它是常用的而是

完成。例如，尽管pdb.py具有up，和向下，gdb的

版本也允许一个数字参数来表示有多少地方上涨

或者下来 - 这又是一件非常容易入侵的事情。怀疑有人在

有点发现这很有用，所以它被添加了。毫无疑问，有使用这个的
程序员。可能还不适用于人们调试Python程序？b $ b调试Python程序？无论如何，我想减少使用我的调试器的人们的学习曲线。


在某些时候有人要求提供GUI界面。我认为没问题，并且

发现这个GUI前端名为ddd。当然它处理gdb和Perl

作为后端。所以要添加我的bash调试器支持，基本上我所做的就是告诉ddd处理这个构造（比如

" breakpoints"）就像gdb一样。有几个地方我告诉ddd

不要跟随gdb而是关注Perl，因为所需的范例必须更像是脚本语言而不是编译语言。但是在

结束时，在ddd中添加对bash的支持要简单得多

并且比我发明自己的调试器需要更少的思考

命令集。


好​​了这个完成后我启动了ddd，我注意到当我的

光标悬停在某些按钮上时请参阅简短描述

该命令的作用。还有一个名为custom

bash的按钮。并且有所有这些设置变量。但是我不记得
记得添加一个用于自定义的框小部件或记住我使用工具提示修改的任何代码

。它是怎么做到的？我非常好，并且不得不找出答案。


你看，因为我甚至复制了gdb''info"的输出格式，

" set"和显示命令，ddd正在做的是自己运行这些命令

并解析输出;它然后使用该输出形成

工具提示并创建自定义框。


当然，当我最近为GNU Make添加调试器时

（ http://bashdb.soruceforge.net/remake ）我再次遵循这个

原则。再次它是有帮助的。


总之，我认为复制或跟踪现有的命令集可能

也是一件好事。 pdb.py.

Okay, a bit of an exaggeration.

Recently, I''ve been using Python more seriously, and in using the
debugger I think one of the first things I noticed was that there is
no "restart" ("R" in perldb) or "run" (gdb) command.

I was pleasantly pleased discover how easy though it was patch pdb.py
and pdb.doc; my patch for this is here:
http://sourceforge.net/tracker/index...70&atid=305470

Encouraged, the next thing I noticed lacking from my usual debugging
repertoire was gdb''s "frame" command which is the absolute-position
version of "up" and "down". Clearly since "up" and "down" are there,
adding a "frame" command is also pretty simple.

Perhaps I should explain that I noticed the lack of and wanted a
"frame" command because I had noticed that prior to adding "restart"
that when the program was restarted through a post-mortem dump, the
first line number in the post-mortem dump was not getting reported. So
Emacs was showing a weird position in the source; it was confusing and
not clear that a restart had actually taken place. When Emacs and the
debugger are out of sync, my usual way of fixing this is by issuing
"frame 0", which usually means go to the top (or is it bottom?) of the
stack which has a side effect of forcing emacs to update the display.

Well, so now we get to the second issue. Python''s stack numbering is
different from the way most (all?) other languages. And "up" and
"down" in pdb.py follow the Python notion of direction rather than
what is common among debuggers. Yes, I realize Python''s stack
numbering is the one true the right way; I have no doubt that Python
programmers draw their trees with the root at the bottom. So at least
for now I hacked in "frame -1" to mean what is generally called "frame
0" in other debuggers. And "frame 0" in my private hacked pdb.py goes
to the most least-recently encountered entry or the grand-daddy place
which calls all of the others.

Finally, we come to listing breakpoints. Showing my gdb orientation,
the first thing tried and looked for was "info break". Nope, not
there. For a while I just thought one just couldn''t list breakpoints
and lived with that. Then when I decided I''ll hack in an "info break"
I realized that if you type "break" without any arguments it lists the
breakpoints. (And yes, I see that the behavior is documented.)

In fact the breakpoint-listing output looks similar to what gdb
uses. That''s nice, but in both gdb and Perl''s debugger a "break"
without an argument *sets* a breakpoint at the current the line, it
doesn''t list it.

Here I''m in a little quandary as to what to do. My take would be to
just change the behavior of break so it works like the other debuggers
mentioned. In contrast to say the "frame" command, I fail to see how
pdb.py''s lingo for "list breakpoints" superior. In fact it seems
inferior. If one wanted to extend the debugger command set to include
a "list information about breakpoint number n" (which gdb does by
"info break n"), I''m not sure this would fit in with the existing
lingo.

My guess is that pdb.py started as a small undertaking and grew
without all that much thought or concern as to what a full debugger
command set should or would be.

So what I am suggesting is that it would be helpful to just follow an
existing debugger paradigm (or follow more closely) so folks don''t
have to learn yet another interface.

Let me close with a rather pleasant experience when I tried something
like that in my debugger for Bash (http://bashdb.sourceforge.net). In
doing that I decided that I''d just try follow the gdb command set. Not
that I think gdb''s is the most wonderful, orthogonal or well-designed
command set, but just that it is commonly used and rather
complete. For example, whereas pdb.py has "up" and "down", gdb''s
version also allows a numeric argument to indicate how many places up
or down - again something pretty easy to hack in. No doubt someone at
some point found this useful, so it was added. And no doubt there are
programmers who use this. Might that not also apply to people
debugging Python programs? At any rate I wanted to reduce the learning
curve of folks using my debugger.

At some point someone asked for a GUI interface. I thought okay, and
found this GUI front-end called ddd. Naturally it handled gdb and Perl
as back ends. So to add in my bash debugger support, basically all I
had do do was tell ddd that handling this construct (say
"breakpoints") is like gdb. There were a few places where I told ddd
not to follow gdb but Perl instead because the paradigm needed had to
be more like a scripting language than a compiled language. But in the
end, adding support for bash inside ddd was much more straightforward
and required much less thought than if I had invented my own debugger
command set.

Well after this was done and I fire up ddd, I notice that when my
cursor is hovering over some of the buttons I see short descriptions
for what that command does. And there is this button called "customize
bash" and in that there are all these setting variables. But I don''t
remember adding a box widget for customization or remember any code
that I modified using tool tips. How did it do this? I was very
curious and had to find out.

You see, because I even copied the output format of gdb''s "info",
"set" and "show" commands, what ddd is doing is running these commands
on its own and parsing the output; it then uses that output to form
tool tips and create a customization boxes.

So of course when I recently added a debugger for GNU Make
(http://bashdb.soruceforge.net/remake) I''ve again followed this
principle. And again it''s been helpful.

In sum, I think copying or following an existing command set might
also be a good thing to do in pdb.py.

推荐答案

" R.伯恩斯坦" < RO *** @ panix.com>写道：

"R. Bernstein" <ro***@panix.com> wrote:

好的，有点夸张。

最近，我更认真地使用Python，并且在使用
调试器时我认为一个我注意到的第一件事就是没有重启。 （per中的R）或run中的R。 （gdb）命令。

我很高兴发现它是多么简单，虽然它是补丁pdb.py
和pdb.doc;我的补丁就在这里：
http://sourceforge.net/tracker/index...70&atid=305470
....好吧，现在我们来看第二期。 Python的堆栈编号与大多数（所有？）其他语言的方式不同。并且向上并且向下在pdb.py中遵循Python的方向概念而不是调试器中常见的东西。是的，我意识到Python的堆栈编号是正确的方式;我毫不怀疑Python程序员用底部的根绘制树。所以至少现在我攻击了帧-1。通常称为帧
0的意思是指在其他调试器中。并且帧0和帧0在我的私人黑客pdb.py去了最近最近遇到的条目或者爷爷爸爸的地方
其他所有人。

最后，我们来到列出断点。显示我的gdb方向，
尝试和寻找的第一件事是信息中断。不，不是那里。有一段时间我只是觉得一个人不能列出断点
并与之共存。然后，当我决定我会破解信息中断时，我意识到如果你键入break，那么没有任何参数，它列出了
断点。 （是的，我看到行为已被记录。）
....所以我建议的是，只需遵循现有的调试器范例（或者更密切地关注）就行了伙计们不必学习另一个界面。

Okay, a bit of an exaggeration.

Recently, I''ve been using Python more seriously, and in using the
debugger I think one of the first things I noticed was that there is
no "restart" ("R" in perldb) or "run" (gdb) command.

I was pleasantly pleased discover how easy though it was patch pdb.py
and pdb.doc; my patch for this is here:
http://sourceforge.net/tracker/index...70&atid=305470 .... Well, so now we get to the second issue. Python''s stack numbering is
different from the way most (all?) other languages. And "up" and
"down" in pdb.py follow the Python notion of direction rather than
what is common among debuggers. Yes, I realize Python''s stack
numbering is the one true the right way; I have no doubt that Python
programmers draw their trees with the root at the bottom. So at least
for now I hacked in "frame -1" to mean what is generally called "frame
0" in other debuggers. And "frame 0" in my private hacked pdb.py goes
to the most least-recently encountered entry or the grand-daddy place
which calls all of the others.

Finally, we come to listing breakpoints. Showing my gdb orientation,
the first thing tried and looked for was "info break". Nope, not
there. For a while I just thought one just couldn''t list breakpoints
and lived with that. Then when I decided I''ll hack in an "info break"
I realized that if you type "break" without any arguments it lists the
breakpoints. (And yes, I see that the behavior is documented.) .... So what I am suggesting is that it would be helpful to just follow an
existing debugger paradigm (or follow more closely) so folks don''t
have to learn yet another interface.

我很失望，没有看到任何回复。

我经常使用pdb，因为我的大多数调试需求都很简单，而且我不需要/想要开销或

重型gui调试器的并发症。


多年前我用的ddd很少，但

与现有工具的兼容性我认为是一大优点。

我当然会考虑使用这样的组合，

，即使没有ddd，我认为对现有工具的行为类似

是一件好事。


我希望有一些其他的问题得到

有一天得到解决：

- 没有办法（我知道）开始一个python脚本

来自命令行，调试器处于活动状态;

我总是要修改源代码以插入一个

pdb.set_trace（）。我想要一些类似于Perl的

-d选项。

- 异常通常不会停止调试器的常规

他们在哪里发生了;相反，你被抛弃

到更高（更低？）的堆栈框架中并且必须

导航回到框架中发生异常

。

- 它需要类似于Perl调试器的

X命令来显示关于

对象（值和属性）的完整信息。

- 帮助命令很蹩脚，只给出一个列表

命令（通常是单个字符）

没有暗示它们是什么执行。

I was disappointed not to see any replies to this.
I use pdb a lot because most of my debugging needs
are simple, and I don''t need/want the overhead or
complications of a heavy duty gui debugger.

I used ddd only little many many years ago, but
compatibility with existing tools I think is a big plus.
I would certainly consider using such a combination,
and even without ddd I think being behaving similarly
to existing tools is a "good thing".

I hope some of the other problems with it get
addressed some day:
- There is no way (I know of) to start a python script
from the command line with the debugger active;
I always have to modify the source to insert a
pdb.set_trace(). I would like something like Perl''s
-d option.
- Exceptions often don''t stop debugger in routine
where they occurred; instead you are dumped
into a higher (lower?) stack frame and have to
navigate back to the frame the exception
occurred in.
- It needs something like the Perl debugger''s
X command to display full information about
an object (value and attributes).
- The help command is lame giving just a list
of commands (which are often a single character)
with no hint of what they do.

ru***@yahoo.com 写道：

ru***@yahoo.com wrote:

我希望有一天能解决其他一些问题：
- 没办法（我知道）从调试器激活的命令行启动python脚本
我总是要修改源代码插入一个
pdb.set_trace（）。我想要像Perl的
-d选项。


您可能想尝试ipython（来自
的当前候选版本 http://ipython.scipy.org/dist/testing/ ，在这个

前面有很多改进。 ％pdb魔法将触发任何

未捕获异常的pdb自动激活，''％run -d''将在

pdb的控制下运行你的脚本，无需对源代码进行任何修改。

- 异常通常不会在常规中停止调试器发生的地方;相反，你被倾倒到更高（更低？）的堆栈框架中，并且必须导航回到发生异常的框架。
- 它需要类似于Perl调试器的东西's命令显示关于对象（值和属性）的完整信息。

I hope some of the other problems with it get
addressed some day:
- There is no way (I know of) to start a python script
from the command line with the debugger active;
I always have to modify the source to insert a
pdb.set_trace(). I would like something like Perl''s
-d option.
You may want to try out ipython (the current release candidate from
http://ipython.scipy.org/dist/testing/, which has many improvements on this
front). The %pdb magic will trigger automatic activation of pdb at any
uncaught exception, and ''%run -d'' will run your script under the control of
pdb, without any modifications to your source necessary.
- Exceptions often don''t stop debugger in routine
where they occurred; instead you are dumped
into a higher (lower?) stack frame and have to
navigate back to the frame the exception
occurred in.
- It needs something like the Perl debugger''s
X command to display full information about
an object (value and attributes).

ipython附带的pdb也被修改为有选项卡完成，颜色

突出显示列表和比默认pdb更好的堆栈处理。

通过选项卡完成，动态探索对象是微不足道的（更好的

恕我直言，而不是在屏幕上倾倒一个巨大的命名空间。


问候，


f

The pdb that ships with ipython is also modified to have tab completion, color
highlighting for listings and better stack handling than the default pdb.
With tab completion, it is trivial to explore an object dynamically (better
IMHO than dumping a potentially gigantic namespace on screen).

Regards,

f

ru***@yahoo.com 写道：

" R.伯恩斯坦" < RO *** @ panix.com>写道：

"R. Bernstein" <ro***@panix.com> wrote:

所以我建议的是，只需遵循一个现有的调试器范例（或者更密切地关注），这样人们就不用了学习另一个界面。

So what I am suggesting is that it would be helpful to just follow an
existing debugger paradigm (or follow more closely) so folks don''t
have to learn yet another interface.

实际上，你并不是在谈论改变范式。你是在讨论命令集的小调整。

我很失望没有看到对此的任何回复。
我使用pdb很多因为我的大多数调试需求都很简单，而且我不需要/想要重型gui调试器的开销或重复。

Actually, you''re not talking about changing the paradigm. You''re
talking about minor tweaks to the command set.
I was disappointed not to see any replies to this.
I use pdb a lot because most of my debugging needs
are simple, and I don''t need/want the overhead or
complications of a heavy duty gui debugger.

我也没有多少使用pdb - 而且我写了很多* Python。当Python中出现问题时，它会告诉你到底出了什么问题，

哪个变量，以及文件和行nubmer出错了 -

以及一个回溯告诉你代码到底是怎么回事
那里。这足以追踪你在

练习中遇到的大多数错误。如果没有，而不是将应用程序加载到调试器

和futz，那么启动解释器更简单，导入

模板行为不端，使用虚假行为实例化和实验

类。如果您编写的代码包含

相当小的方法/函数，这些工具*非常好用于

追逐错误。我的开发环境允许我从

编辑类到在解释器中测试新代码中的一些

键击意味着它非常*易于处理用。


鉴于这两个工具，我发现我每年可能会使用一次pdb。我可能

如果它消失了就不会错过它。我肯定不会花费任何时间来处理它。当然，如果你有兴趣延长它

- 玩得开心。


< mike

-

Mike Meyer< mw*@mired.org> http://www.mired.org/home/mwm/

独立的WWW / Perforce / FreeBSD / Unix顾问，电子邮件以获取更多信息。

I don''t use pdb a lot either - and I write a *lot* of Python. When
something goes wrong in Python, it tells you exactly what went wrong,
with which variable, and the file and line nubmer it went wrong at -
along with a backtrace telling you exactly how the code got
there. That''s sufficient to track down most bugs you run into in
practice. If not, rather than load the application into a debugger
and futz with that, it''s simpler to fire up the interpreter, import
the module that is misbehaving, instantiate and experiment on the
classes with bogus behavior. If you write code that consists of
reasonably small methods/functions, these tools work *very* well for
chasing down bugs. That my development environment lets me go from
editing the class to testing the new code in the interpreter in a few
keystrokes means it''s *very* easy to deal with.

Given those two tools, I find I use pdb maybe once a year. I probably
wouldn''t miss it if it vanished. I''m certainly not going to spend any
time working on it. Of course, if you''re interested in extending it
- have fun.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

这篇关于pdb.py - 为什么这个调试器与所有其他调试器不同？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！