So a better idea is to put a breakpoint in your code instead. But you can't execute the next lines of code, as a real debugger would do. Putting a breakpoint in your code #Įmbedding an IPython session in the code is fine if you want to see what's going on at a given line. Let's say we have the following file: a = 10Īs you can see, I changed the value of the a variable and the new value persisted after I closed the IPython session. Here is a short demo of embed() in action. So you can modify some variables or functions (you can even decorate functions with some simple logging) and see how the rest of the code will behave. One nice thing about this approach is that all the modifications done in IPython will persist when you close it. When you are done, you just close the session ( Ctrl+d) and the code execution will continue. You can poke around and see what's going on in the code. When you run your code and the interpreter gets to the line with the embed() function, it will open an IPython session. That way, I won't forget to remove it when I'm done □. And, since putting multiple statements on the same line is a bad practice in Python, every code linter will complain about it. I like to put those two statements in the same line: from IPython import embed embed ( ) All you need to do is to put the following lines in your code: from IPython import embed ![]() The most common case for me is to embed an IPython session in the code. Here is how I'm using it: Embedding IPython session in the code # I've been using VS Code for almost two years, but I don't remember when was the last time I used the built-in debugger. You can always use the standard Python debugger pdb, but a much better alternative is to use IPython as your debugger. Those are text editors! And even though I have seen people being more productive in Vim than most of the P圜harm or VS Code users, text editors are not created with a powerful debugger in mind. According to the Stack Overflow Developer Survey Results 2019, 30.5% of developers are using Notepad++, 25.4% Vim, and 23.4% Sublime Text. But, adding some print statements and then looking at the logs should be fine.Īnd not everyone is using an IDE with a good debugger. You can't easily attach a debugger to your production code without impacting your users. ![]() And sometimes, it’s the only way that you can debug your code. Quite often, it’s all you need to find the bug. Sounds familiar? There is nothing wrong with using print for debugging. Never mind that 5 minutes later our one print statement turns into: print (a_varible ) "I think there is a bug with this one variable. "I'm going to start a debugging session" sounds heavy. Yet, people still use print statements for debugging their code. It makes working with large codebase much easier and helps newcomers get up to speed on a new project. Don't get me (or Tenderlove) wrong - the debugger that comes with a good IDE is one of the most powerful tools that a programmer can have! You can easily put breakpoints in your code, move around the stack trace or inspect and modify variables on the fly. ![]() The gist of it is to show you that, in many cases, you don't need a full-fledged debugger. There is a great article from Tenderlove - one of the core Ruby and Rails developers - called "I am a puts debuggerer", that I enjoyed when I played with Ruby.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |