Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS Zed Shaw's Debugging Tips in Learn Python the Hard Way

ArtOfWarfare

ArtOfWarfare

macrumors G3
Original poster
Nov 26, 2007
9,557
6,058
I thouroughly enjoyed Zed Shaw's Learn C The Hard Way so when it came time for me to learn Python yesterday, I turned to his Learn Python the hard way, but I was shocked at the contents of chapter 36, which is on debugging.

Here's a link to the chapter:

http://learnpythonthehardway.org/book/ex36.html

Some of his advice sounds downright bad, namely:

  1. Every if-statement must have an else.
  2. If this else should never be run because it doesn't make sense, then you must use a die function in the else that prints out an error message and dies, just like we did in the last exercise. This will find many errors.
Click to expand...

Obviously I'm no Python expert, having only started this book 60 hours ago or so, but since this is very wrong for every language that I do know quite well, it seems like it's probably very wrong in Python as well.

For example, you have a function that can return early if a condition is met. That if doesn't need an else, but it shouldn't die either. Alternatively, maybe you have a function that contains some initialization code that needs to be run if a variable hasn't been properly initialized yet (that pattern is all over Obj-C, and I've seen in in many other languages too,) - and then it needs to do stuff with that variable once it's initialized. That initialization check doesn't need an else, and it shouldn't die if the condition isn't met.

Later in the same chapter he says:

  1. Do not use a "debugger". A debugger is like doing a full-body scan on a sick person. You do not get any specific useful information, and you find a whole lot of information that doesn't help and is just confusing.
  2. The best way to debug a program is to use print to print out the values of variables at points in the program to see where they go wrong.
Click to expand...

Um... no? Totally wrong? I don't actually have an IDE for Python yet (any suggestions?) but that sounds like a gross misuse of print to me. Shouldn't print be used only to log significant events in your program, not every little thing that happens? Shouldn't you use a debugger and breakpoints and stuff? (IDK, he hasn't brought up anything like this so far, but I imagine such features probably exist in some IDE somewhere.)

Am I wrong in thinking the author's tips here aren't just useless, but harming naive novices who will now refuse to learn to use a debugger and will insist on having debug statements all over their code?
 
A

Ap0ks

macrumors 6502
Aug 12, 2008
316
93
Cambridge, UK
If it's a small program and you aren't using an IDE (or you may not have much knowledge in how best to use a debugger) then using prints is a great way to find issues. You can easily compare what the program is printing to what you expect it to be printing and if they don't match then you know which section of code contains a bug.

As for the else statements it's not something I've ever done religiously but I can see where he is coming from. It will help you find conditional statements that aren't working correctly, if your application dies and logs a message you know that you have a faulty if statement in your code or something the user is doing hasn't been accounted for in code.
 
Y

ytk

macrumors 6502
Jul 8, 2010
252
5
The if/else thing makes no sense. If the “else” should never be run, then that means the “if” should always be run. And if the “if” should always be run, why bother putting it in at all?

The only time I can see this making sense is when you want to actually raise a fatal error because you believe the test might fail sometimes—e.g. the Perl “open or die” pattern.

As for the print debugging, it actually comes in handy sometimes. Especially if you're writing a short program, it's easier than breaking out the debugger, and often helps you get a handle on exactly what the internal state of the program is. For example, Ruby has a nice function that's simply called “p” which prints out any object passed to it, along with things like class information, instance variables, and so on. It's a great way to at least get your bearings if you're totally confused as to just what the heck is going on. So yeah, I wouldn't say to never use the debugger, but there's some benefit to using print statements for debugging purposes.
 
Last edited:
S

subsonix

macrumors 68040
Feb 2, 2008
3,551
79
ytk said:
The only time I can see this making sense is when you want to actually raise a fatal error because you believe the test might fail sometimes—e.g. the Perl “open or die” pattern.
Click to expand...

The Perl die pattern was what I thought of as well. But why not test for the failure case directly in the if statement? If you get past that, there is no need for an else.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom