为什么Python要以打印日志为荣 , 以单步跟踪为耻？

打印日誌查錯效率是O(log n), 單步跟蹤是O(n).
况且單步跟蹤還有很多局限性.

@013231 这个效率的说法很有意思，能细说下吗？
局限性在什么地方呢？

顶1l

@013231 请问这是如何计算出来的?

打印日志第n次成功找到bug的概率是1/n,1/(n-1),1/(n-2)...-> 1，把所有期望值求和取平均=
(1+1/2+1/3+...+1/n)/n=1/n在[1,n]上的定积分=ln(n)-ln(1)=ln(n),所以其复杂度为O(ln n)

单步跟踪找到bug的概率期望值为(1+2+3+...+n)/n=(n+1)/2 所以其复杂度为O(n)

@suckli 看上面

@skyleft 概率算法有问题，打回去重算～

@skydiver 第一个不需要除n

Python打日志不用print啊，用logger打，而且还能控制打印的粒度。

@013231 单步跟踪可以用breakpoints的

一直用print大法调试，现在正努力摆脱中。原因有两个，一个是学了functional programming另一个是看了rob pike的一个建议。把rob pike的帖子贴这里，这才是正确的debug方法，

A year or two after I'd joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model.

Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.

I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.

@kid7st
@skyleft 其实简单说就是打印日志可以二分查找，单步只能一步一步跟踪，所以一个是O(log n)一个是O(n)

笑笑就好，有的还不能当真。用调试器又不光是单步，而且用调试器和打印日志也不矛盾

@skydiver 二分，这个明白了。thanks！

@haohaolee 同意

就应该说是调试器。
打日志，会直接影响原代码（虽说不会影响逻辑）。

调试器一般那么多功能，运行到指定行，运行到返回什么的
单步的话，我一般是看内存里面变量的值的变化。哪个值不对，在什么地方不对，马上就知道原因。
(当然我说的是java, python还不会用调试器)

如果不是逻辑上的问题，打日志，完全可以。
但是如果是逻辑上的问题，那就蛋疼了。

print一般都会有日志级别，正式发布的时候不会开那么低的，对源代码不会有影响
用print的时候，输出的地方一般都非常关键，而且信息更为实用
调试时，print更容易在非常大段的代码中定位
调试后，print依旧留在代码中，为下次调试带来便利

不管是python还是c/c++，都习惯打日志，而不喜欢用单步调试工具。

单步调试工具用起来太蹩脚了，效率低。

本来想说些什么的，但有些东西只有你经历过才能有体会，不经历过说了也不能完全理解，经历过不说也会明白，所有我只能建议楼主，从今天开始，在程序的重要步骤，检测到异常输入的时候，进入了不大可能进入的 else 语句的时候，用 logging 模块打印状态信息，包括现在正准备或者已经做了什么，和关键变量的值。等楼主这么做一段时间之后，自然就明白了。

thinking bug -> logging bug -> digging bug

原来有明白人知道断点的。

空格缩进这个不能理解， html和代码混杂的project，如果用空格缩进，会相当难受，有时候会非常在意那一点文件传输的体积。

@kid7st 局限性包括:
1. 單步調試會破壞程序的時間特性. 即: 原本併發的操作, 在單步調試時不再併發; 原本在短時間内相繼執行的操作, 單步調試時間隔變長.
2. 對於某些發生頻率非常低的Bug, 恐怕你没有時間開着調試器等到Bug出現.
@jianingy
我們對單步跟蹤的理解有所不同, 在我看來斷點已經不算"單步"跟蹤了.
另外在我看來, 打印日誌更有利於"thinking before debugging" -- 寫一條日誌語句的勞動量遠大於讓調試器跑到下一步或設置一個斷點, 在决定如何寫日誌時, 你不得不仔細思考Bug是如何發生的.

@avatasia 这里说的是Python，不是html。

Python的PEP8标准应该作为严格执行。

@013231 其实打印日志的问题上我们的理解也点不同。打印运行日志是必要的也是很有技巧的，大部分生产问题都可以通过运行日志定位。而我所尽量规避的是通过不停在代码中加print语句来调试程序的方式。

@BOYPT 他说的可能是 PSP

@jianingy 用logger取代print就好了，多简单的事情

我以前用断点多，现在用log多，不知道算是进步还是退步。
现在偶尔还是会用断点，不过仅限于C#之类，感觉脚本语言用log更方便，所以python我用log。

一般我是先print，要是还找不到就debug，要是还找不到就去逛逛v2ex。。好吧我要去继续找bug了再见。

@013231 俺们家VS可以冻结线程，指定线程的完成顺序这个还真只能Debug