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

Discussion in 'Mac Programming' started by ArtOfWarfare, Jul 3, 2013.

  1. ArtOfWarfare macrumors G3


    Nov 26, 2007
    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:


    Some of his advice sounds downright bad, namely:

    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:

    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?
  2. Ap0ks macrumors 6502

    Aug 12, 2008
    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.
  3. ytk, Jul 4, 2013
    Last edited: Jul 4, 2013

    ytk macrumors regular

    Jul 8, 2010
    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.
  4. subsonix macrumors 68040

    Feb 2, 2008
    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.

Share This Page