I don’t use debuggers, print() is my debugger. To each their own. I find I learn way more about whats going on with print than if a debugger is doing all the work for me. But I also learned most of my python without a ‘interactive’ editor that would point things out for me. Just recently started using visual studio, and sometimes just sometimes I’d rather be back in an editor that didn’t always try to ‘help’ me (bluefish, atom, notepad). Try it out sometime. Take a bit of code, in notepad, or atom, and see how much you can debug without a debugger or the hints from the editor. You might find that useful in learning whats going on too. Sometimes a debugger won’t pick up a ‘bug’ because what you wrote is valid, it’s just not what you intended.
–A computer will do exactly what you tell it to, always.
This is where the human error comes in.
Agreed but the ability to view/change values on the fly is the strength of a debugger, even pdb.
Ive been doing that for awhile. Its how I first learned to find my errors. I did the print statement thing this time but if I get to the point where I have to analyze more the 500 lines its just too time consuming for me. I learned more about how data gets processed with the debugger than with the print statements in a much shorter amount of time. I can see all data state info at each occurence. It even gives me inside information as to how the IDE makes calls to access modules if you configure it that way. Its just my preference I guess. Different strokes I guess but thanks for the tip. I finally got PYcharm to work with the 3.8 interpreter(it defaults to 2.7 which is useless to me). Anyway thanks again for the advice.
Another awesome way to see what your program does is to use pdb with set.trace().
Set the following on top of your code:
import pdb
pdb.set_trace()
and you can step through your code one call at a time. Type “n” (for next) and press Enter for each step.
Hat tip to @ulfen69 for this (Very confused how my code executes through my script)
Here are the docs for Python3.6: https://docs.python.org/3.6/library/pdb.html
What is invaluable for me in a debugger is the ability to see the state information for every variable at each line. Its nice drilling into functions and seeing the code from imported modules but seeing the values at any given moment in time is how Ive learned and understood whats going on the best. I tried out pdb…does it do that? I couldnt find a command to accomplish that.
Maybe that is what you’re looking for p expression:
https://docs.python.org/3.6/library/pdb.html#pdbcommand-p
Hello @Jharris4854
I guess that @nellietobey ’s suggestion suits your needs best.
I also put in print statements in the code to see what result I got while coding.
I use to put in both the object to watch and a ”comment”
this_year = 2019
next_year = this_year + 1
print(next_year, ”next_year”)Here I expect to see 2020. If not, I did something wrong.
But then I hopefully find it quickly.
It is worth adding that many of Zed’s tips in this LPTHW course is for beginners. It can be baffling for total beginners to load up and IDE, set the environments correctly, become familiar with basics functions and the IDE prompts/auto-functions, as well as learning programming for the first time.
This so why many courses talk about terminal and editor only. Stick to learning code not the IDE. But if you are already familiar with an IDE, and another language, then clearly you’ll benefit from it’s known features whilst learning new languages. For me, @Jharris4854 is not a total beginner and should explore with as few distractions as possible. If this means Netbeans and debugger, go for it!
Ironically, I’m learning Java at present and absolutely avoiding Netbeans/Intellij in favour of Vim/Term2
I ended up doing something very similar to this before I jot Jetbrains working
There maybe better support out there. At the time I learned Java, Netbeans was just the IDE the instructor used. It wasnt even the industry preferred IDE; Eclipse was. But I used Eclipse for learning Android…so I guess to each his own. I wasnt impressed with Netbeans python support but it wasnt meant to be bug free. I found alot of syntax errors and misuse of Exception handling in the .py files after I installed the plugin. The most up to date Python plugin for netbeans was for 8.1. I had 8.2. I didnt think it would make a big difference but it most certainly did.
I think you are correct about that. Thanks for the link!
I’m curious @Jharris4854 when you say “where I have to analyze more the 500 lines its” are you doing the following:
- You type in all 500 lines of code.
- You run all 500 lines of code 1 time.
- You attempt to fix bugs in all 500 lines of code.
If you are then that’s something you should change. I work like this:
- I write 2-10 lines of code, whatever is a “runnable chunk”.
- I review those lines like I would edit an essay I wrote.
- I run the script or some automated test script to confirm my 2-10 lines work.
- I then only first the 2-10 lines or possibly others I’d written before, but not 500 lines.
- I repeat this until I’ve written all 500 lines, then I review it again and try to clean it up. Sometimes this means I delete it and write it all again simpler.
Let me know how you work. Maybe record it and play it back at high speed.
I do have a bad habit of taking on projects out of my league. My style could use alot of revision. Your book is helping me with alot of that. I use to use debuggers more when Id write most of a program(like when I used Java to write a game-Othello)…some of the code Id google. Then Id follow the debuggers bread crumbs line by line. Since I started this book of yours Ive used Atom as you suggested. Until Exercise 41 where I got stuck. Im using Pycharms now. But I learned coding using the method of writing a paper. Rough draft then revise,revise,revise. That is how I learned to write. (Mississippi has the lowest educational standards in the country- or did at the time I was in high school and college. Maybe this isnt the best way to ‘write a paper’ but tbh, the fact I made it to this point is significantly impressive IMO…lol) Im seeing that isnt the best way when Im just learning. But It is quicker than jumping from one program to the other to run and test. I like the fact debuggers have the python interpreter built in. About the 500 lines: I did that when I was learning Java. Like I said I realize that I should start small then just add to it. Im learning alot about OOP on youtube. This one guy Corey Shaeffer(sp) has explained OOP more clearly than Ive ever heard it before. I realize this book is an exercise book, but I need some theory on OOP bc I never fully grasped it
Why not try a test first approach. That way you’ll be forced to write smaller chunks. Research ‘TDD’ or ‘red, green, refactor’.
ok Ill check that out. Im doing smaller chunks now. It has gotten to the point I will be way too overwhelmed doing it any other way.
Alright, well at least you know what you need to improve on. People like to say that you can learn “bad habits” in programming, but it’s really not true. It’s not like playing guitar where if you learn a sequence wrong you actually physically learn it through repetition and then can’t physically undo it easily. Programming is a mental activity so when you have a “bad habit” you just…stop doing it. You aren’t forever tainted, and usually people claiming you have a bad habit are actually just rote repeating some junk trend they heard from other famous programmers. Give them a year and they’ll be ranting about some new thing as the “bad habit”.
So, what you should do now is just … stop doing that. To keep it simple, practice just running your code after every line, even if you know it won’t work. You just write a line, alt-tab to the python window, run it, alt-tab back to code and write more (or fix what you just wrote). That’s pretty much how I code.
Can anyone please explain what the code in line 46 does?
“for sentence in snippet, phrase:”
Lots of details on this thread:
I came across a page that runs code line by line.
http://pythontutor.com/visualize.html#mode=edit
I think it runs like a debuger. I have yet to use one though so i dont know how it runs. I’ve been running the print(>>>)lines for that. but when it comes to following the ‘flow’, print() doesnt help me.
I just put in some random for loops, dict, and what not, and it helped me see the code run. I dont think i would try ex41 lol, but it may run it.
You can also use the built-in debugger:
https://docs.python.org/3/library/pdb.html
It’s pretty easy to use but you do have to manually add it.