I am attending my first conference - Python Web Conference 2021 - since the start of the pandemic right now and I'm so excited! It's a fully remote conference that runs for about six hours per day, everyday this week. I'm going to write a few blog posts about what I am learning so stay tuned.
Today, I did a workshop on debugging given by Philip Bauer.
Here are my notes as well as some thoughts that I added :)
Types of Bugs
He started off the workshop going over the different types of bugs that we can see in software development. The two main categories are obvious bugs that throw an exception/give you a traceback and hidden bugs that don't throw an error but are seen through your program not functioning as you expect. There are also some subtypes like bugs that change based off of the situation, hidden exceptions, and unwanted side-effects.
Preventing Bugs
After understanding about the types of bugs in a program, it's important to understand how to prevent these bugs. Here are some tips Philip had for preventing bugs:
- You can prevent errors by writing readable code. He suggests writing code as if you are reading the code 10 years in the future. Ask yourself, will you or other people be able to understand this just by reading what you wrote? If not, update your naming conventions, define datatypes, add docstrings, etc.
- Develop incrementally; write code in small batches and then run the code every time you add something.
- Write tests for code. You don't have to use TDD, but at least write tests to cover the main functionality of the codebase. This makes sure the code behaves as you expect and prevents bugs from being introduced that are caused by breaking older code.
Debugging Steps
Looking at your code
- Look over your code, section by section, for obvious errors.
- Make sure you know what every line is doing.
Read the Tracebacks
- Read the message and every line.
- The most important thing about Tracebacks is to not jump to conclusions and read the traceback.
How to Fix the Bug
- Reproduce: you must first be able to see the bug
- Isolate: understand where the bug is coming from
- Eliminate: go step by step through the code to fix the bug
Debugging Tools
Print Statements
He started off talking about how the most common debugging method, print() statements. This is pretty much the the way that every developer starts debugging problems. The advice that he gave was to use f-strings in print statements and print out not just the value of a variable but also the type:
print(f"name: {name}, type: {type(name)}")
PDB
This is a debugging tool that is built into Python. You basically add breakpoint()
statements to your code (this was pdb.set_trace()
before Python version 3.7 came out), then run your code and it will stop execution at those breakpoints so you can interact with any variable in that scope. There are also lots of commands that you can use to see the current state of your program and step through the rest of the execution of the program. ll
and n
are two of these:
While PDB is helpful, there are some obvious things that are missing like syntax highlighting (see screenshot above) and opening an interactive terminal at any point. This is why Philip recommended using PDB++.
PDB++
This is a Python package that you can install in your project (or globally if you want) that will replace Python's default PDB commands and add quite a few new ones.
Personally, I had tried PDB in the past, but ended up sticking with IDE developer tools, like the ones in VSCode and PyCharm that provide a nice interface for debugging. Now that I have tried out PDB again, and PDB++ for the first time, I can definitely see where it might be useful for when I write scripts with Vim or am SSH'd into a server. There are also some GUI interfaces for PDB that look pretty good but I haven't tried any of them out yet.
Day #1 Overall
I definitely enjoyed the workshop today as well as the conference in general. They are using a platform called LoudSwarm to host the conference which has a really nice interface. It's easy to navigate and see information and attend talks. You can also, optionally, join a talk as an on-screen participant for Q&A during the session.
The conference also has a Slack group setup with rooms for each track plus extras like #hallway
and #after-event-socials
which makes it feel like a regular in-person conference even though we are remote.
Conclusion
I still have a full week of talks left to attend and I will write a few more posts on things I learn.
Thanks to my company, RocketBuild, for supporting me and giving me the time to attend this week!
Have a great day everyone :)